Gestion complète de Fichier de paramétrage

ca aurait été mieux avec de l'xml, .net core, et des valeurs typées et typables sur autre chose que string, y compris des classes
et je trouve que ca fait beaucoup de code pour pas grand chose du coup

(…)

et pourquoi pas intégrer la création automatique du fichier si celui ci n'existe pas, forcer l'initialisation requise par le constructeur (voire même par un factory static de singleton par fichier qui simplifie encore plus)
et utiliser des propriétés plutôt que des public field !

(…)

au final j'aurais tendance à dire que c'est ni fait ni à faire
étrange parce que le précédent code que tu as posté (je ne sais plus de quoi ca parlait) était quand même mieux ...

(...)

j'ai été retrouver le code en question, c'était la gestion de saisie par textbox en Windows forms
et autant que l'utilisation aurait pu être légèrement plus pratique je n'ai pas réussi à mettre en défaut le système donc c'est plutôt réglo

Salut Pol63,

Je suis d'accord avec toi globalement mon code de gestion des paramètres est très largement améliorable et je comprends largement tes critiques.
Lors d'une prochaine version j'intégrerai notamment la création auto des fichiers.

En revanche pour ce qui est de l'XML c'est vraiment NON.
On peut faire bien entendu une gestion des paramètres en XML, c'est même beaucoup beaucoup plus simple. Ce n'est pas dit d'ailleurs que j'en fasse une un jour…

En revanche l'XML dans un fichier de paramétrage ce n'est pas forcement bon. Il y a beaucoup de programmeur qui n'en veulent pas. Notamment parce que lorsqu'ils ont un client au tel (notamment lorsqu'ils sont en voiture ) et qu'il leur font ouvrir un fichier de paramétrage pour le modifier c'est du chinois pour eux.

Faire de l'XML c'est plus simple pour nous les programmeurs, mais c'est beaucoup plus compliqué pour des personnes qui ne le sont pas.
C'est peut être parce que je suis un peut old school… mais imagine que ton fichier doivent certaines fois être ouvert par un tech responsable de maintenance ( dans le domaine de la mécanique par exemple), et que ton client soit légèrement réfractaire aux balises ouvrante ou fermante et à l'informatique en general…
Je pense par expérience que les risques qu'il te plante ton fichier XML sont beaucoup grand. D'ailleurs dans l'industrie j'ai beaucoup vu plus de fichier paramètre structuré comme ca qu'en xml. Donc c'est déjà fait par plein de gens (depuis ma connaissance du cobol il y a longtemps … ), et c'est pas étrange du tout. C'est juste une question de philosophie...

Donc oui c'est vrais ca fait pas mal de code, mais en partie parce que justement il n'y a pas d'xml et que justement je me suit embêté pour qu'il n'y en ait pas. C'est vraiment volontaire.

ok, je comprends mieux, c'est une question de point de vue

pour moi un fichier de config n'a pas à être ouvert pas quelqu'un qui ne connait pas (voir même n'a pas à être ouvert du tout)
pour ca je fais une interface graphique (qui va modifier le fichier de config), un fichier de config n'est pour moi que de la persistance locale simple

comme quoi c'est pas ni fait ni à faire ^^

après en restant dans ton optique je verrais quand même bien un public static GestParam GetParamFile(string fileName) {} qui s'occupe de créer le fichier si nécessaire et retourne une instance de GestParam qui elle n'a que les méthodes de manipulation du contenu (avec aussi une méthode static pour delete et rendre le constructeur private)
cette instance pourrait être conservée et éventuellement passée en paramètre ce qui permet de continuer de gérer plusieurs fichiers, mais amène au passage l'abstraction sur le nom de fichier quand on passe l'instance à quelqu'un d'autre

La encore je dirais que tu as à la fois tord et raison.
Ca dépends comment on voit les choses.

- Oui : un fichier de config n'a pas à être ouvert par quelqu'un qui ne connais pas… en principe.
Mais : Tous les programmeurs font des bugs, touts les ordi connaissent des pannes, des mises à jours système dévastatrices etc... Et donc il existe toujours des évènements plus ou moins inattendus. Sinon les contrats de maintenance logiciel ca n'existerait pas… Donc, je part du principe que les ennuis ca existe, et que pouvoir faire paramétrer quelque chose par quelqu'un d'autre que moi rapidement ca peut avoir de l'intérêt .

-Tu dis : "Pour ca je fais une interface graphique ": La encore je suis tout a fait d'accord avec toi : moi aussi … en principe.
Parce qu'il faut encore avoir le temps de la faire ( ou meme que le client ait le budget pour que tu la fasse, par ce qu'au bout du compte c'est lui qui paie ). Et dans ce cas d'ailleurs mon programme aurais moins d'intérêt puisque dans ce cas précis il vaut mieux effectivement un fichier de paramétrage de type xml.

Personnellement, je trouve que tu as une façon tres saine de raisonner, mais trop théorique pour moi. En fait si j'allais imager tu serait un mathématicien et moi un physicien ou un mécanicien . Moi j'aime bien la beauté des math, mais un moment il faut programmer avec en tête la réalité de la vie, de l'argent et donc tu temps . Je pense que ca serait sympa qu'un jour on développe un code libre ensemble à temps perdu , j'ai peut être meme une idée à te proposer...

Par ce que j'ai une idée de projet qui pourrait rendre vraiment un tres gros service au gens. Mais il me faudrait une personne exactement comme toi. Contacte moi sur mon mail en privé si tu veux que je t'en parle (cf mon code source).

Bonjour,
Projet intéressant mais pourquoi ne pas avoir utiliser les API Windows directement disponible dans le Kernel32 ?

Pour la lecture :
http://pinvoke.net/default.aspx/kernel32.GetPrivateProfileSection
http://pinvoke.net/default.aspx/kernel32.GetPrivateProfileString

Pour l'écriture :
http://pinvoke.net/default.aspx/kernel32.WritePrivateProfileSection
http://pinvoke.net/default.aspx/kernel32.WritePrivateProfileString

Salut,

Ecoute je vais être tres honnête :
D'abord je ne connaissait pas leur existence.
Ensuite, je pense que ce n'offre pas non plus la liberté nécessaire à mon objectif :
Faire un prog un peut a part de ce que l'on vois aujourd'hui ( pas de xml ), qui offre une certaine souplesse et une certaine indépendance vis a vis des API.
Je vais d'ailleurs l'améliorer d'ici la fin de l'année.
Je pense que ce type de code a une durée de vie tres longue...

Salut

Je travaille dans l'industrie automobile depuis plus de 10 ans. En environnement Microsoft ça fait bien longtemps que ces fichiers de configuration "plats" de type .ini ont été abandonnés. Sans aucun jugement de valeur, ceux qui restent ne sont que des reliquats du passé dont on ne peut se débarrasser parce qu'on n'a pas le temps ni les moyens de les remplacer (à l'image des gros systèmes et des applications COBOL).

Il n'y a pas de nouveau développement avec ce genre de chose, même pour une appli faite entre deux portes on a souvent besoin de fichiers permettant de faire des structures complexes (typiquement XML, qui lui même perd du terrain face au JSON). Et même dans le cas où un fichier plat suffirait, on utiliserait un XML ou un JSON basique, parce qu'on reste sur des technos actuelles standard et industrialisables, pour lesquelles il existe plein de bibliothèques éprouvées et qui permettront de faire évoluer de fichier de configuration si nécessaire.

Je rejoins Pol63 sur le fait que ça ne permette pas le typage, du coup ça ne permet pas la validation non plus (comme avec un schéma XSD par exemple).

En résumé je trouve ça beaucoup trop limité par rapport à ce qui existe déjà (et qui est déjà éprouvé, débogué, évolutif, etc. enfin que je peux mettre en prod les yeux fermés).