Je vais moi-même répondre à cette question, mais n'hésitez pas à fournir vos réponses si vous êtes plus rapide que moi ou si vous n'aimez pas ma solution. Je viens de trouver cette idée et j'aimerais avoir des opinions à ce sujet.
Objectif: une classe de configuration lisible (comme un fichier INI) mais sans avoir à écrire (et à adapter Une fois qu'un nouvel élément de configuration a été ajouté), les méthodes de charge et d'enregistrement. Je souhaite créer une classe comme appeler tmyconfiguration.save (héritée de la tconfiguration) devrait créer un fichier comme question: Quelle est la meilleure façon de faire cela?
7 Réponses :
Ceci est ma solution proposée.
J'ai une classe de base p> Les méthodes de charge ressemblent à ceci (Enregistrer la méthode en conséquence): p> function TMyConfiguration.SaveTObject (P : Pointer) : String;
var
Obj : TObject;
begin
Obj := TObject (P);
Result := Obj.ClassName; // does not make sense; only example;
end;
Cela me semble assez correct. Qu'est-ce qui vous fait penser qu'il pourrait y avoir une solution plus intelligente?
@Jeen: L'expérience que dans la plupart des cas lorsque je demande ici, je reçois beaucoup de commentaires intelligents, suggestions d'amélioration et de critique :) En plus de cela, je voulais partager ce morceau de code afin que d'autres puissent potentiellement bénéficier.
Ce serait pour Java.
J'aime utiliser le java.util.properties classe pour la lecture dans les fichiers de configuration ou les fichiers de propriétés. Ce que j'aime, c'est que vous mettez votre fichier avec des lignes de la même manière que vous avez montrées ci-dessus (clé = valeur). En outre, il utilise un # (panneau de livre) pour une ligne qui a un commentaire, comme beaucoup de langages de script.
afin que vous puissiez utiliser: etc alors vous avez simplement un code comme: facile comme ça.
N'aidez pas beaucoup depuis que je demandais que Delphi et la classe que vous proposez est spécifique à Java ...
oui désolé pour ça. Vous n'étiez pas en train de préciser, alors je lui ai donné un coup de feu. La question était libellée très généralement. N'a pas vu votre étiquette Delphes.
En gros, vous demandez une solution à sérialiser un objet donné (dans votre cas une configuration à des fichiers INI). Il existe des composants prêts à ce que vous puissiez commencer à chercher
J'utilise XML pour toutes mes applications comme moyen de configuration. C'est:
J'ai une bibliothèque XML qui le rend extrêmement facile à lire ou à modifier la configuration, sans même avoir à surveiller les valeurs manquantes. Maintenant, vous pouvez également cartographier le XML dans une classe interne de classe pour un accès plus rapide si la vitesse est la question ou certaines valeurs sont en lecture constamment.
Je trouve d'autres méthodes de configuration beaucoup moins facultatives:
Je fais beaucoup de même, mais j'utilise l'assistant de liaison de données XML de Delphi pour mapper le fichier sur des objets.
La chose est la suivante: je pense que les fichiers INI peuvent être facilement compris même par les utilisateurs, mais tout le monde n'est pas capable de comprendre XML. Je sais que je devrais avoir des dialogues de paramètres pour cela, mais j'aimerais que quiconque puisse être capable de modifier les paramètres plus avancés sans plonger dans XML.
Les fichiers XML sont vraiment faciles à lire. Je parle de XML de base ici. Juste des nœuds avec des attributs et des valeurs (texte). Il n'est guère moins lisible par rapport à une INI. OK, vous avez plus de "placage de chaudière" dans les balises. Mais si vous vous inquiétez des utilisateurs modifiant puis faites une interface graphique pour eux. Vous ne pouvez pas éventuellement sur l'utilisateur pour modifier un fichier à lui seul. Même un ini.
Vous avez probablement raison, mais dans mes cas, les utilisateurs sont utilisés pour travailler avec des fichiers INI et je voudrais garder cela. Si j'utilise XML de manière aussi plate (sans profondeur, etc.), il n'y a que beaucoup de frais généraux dans les fichiers.
D'accord, si vous utilisez un XML comme celui-ci, il est préférable de rester avec des fichiers INI. Cela revient également aux outils. Si vous avez les outils appropriés, XML peut être devenu très très puissant, sinon il peut simplement être maladroit. Je n'ai pas dit que les fichiers INI sont mauvais, juste qu'ils offrent moins de flexibilité;)
Si l'utilisateur doit modifier manuellement un fichier de configuration, vous avez déjà perdu la partie.
Ils ne doivent pas. Ils peuvent s'ils veulent modifier des paramètres supplémentaires. La plupart n'ont aucun problème avec la modification d'un fichier INI.
La seule raison pour laquelle les utilisateurs auraient jamais "vouloir", c'est la raison (correcte) que vous avez déjà donnée: "Je sais que je devrais avoir des dialogues de paramètres pour cela." C'était juste. Dire que les fichiers INI sont "assez bons" est un flexible.
Eh bien, c'est au noir et blanc pour moi. Les utilisateurs les plus avancés ne craignent pas de modifier un fichier INI, alors pourquoi encombrer la boîte de dialogue Paramètres avec des paramètres très spéciaux et avancés? En plus de cela, il suffit de conserver la boîte de dialogue Paramètres à jour. Encore une fois: je ne parle pas des paramètres de base ici, je parle de régler les paramètres.
Long? Avec XML, vous pourriez (devrait) générer l'interface utilisateur de manière dynamique! Les fichiers INI sont trop limités pour le faire, mais les fichiers XML ne sont pas; Vous pouvez avoir des attributs pour les noms d'affichage, les types de contrôle, etc. Il est étrange que vous essayez d'essayer simultanément dire que les fichiers XML sont trop compliqués pour qu'un utilisateur puisse comprendre et que vous devriez vraiment avoir une interface utilisateur (avec laquelle je suis d'accord) tout en étant simultanément. Attribuant que seuls les utilisateurs d'alimentation (qui comprendraient XML) feraient cela et que cela fait une interface utilisateur (près de gratuit avec une configuration XML) est trop de travail!
Comme je l'ai dit ci-dessus: nous utilisons actuellement des fichiers INI et cela ne signifie rien qui devrait changer. Je ne suis pas contre XML et j'accepte votre opinion que tout devrait être intégré à l'interface utilisateur. Mais ce n'était pas vraiment ma question. Ma question était de créer un fichier ini-fichier comme un fichier de configuration, alors nous devrions peut-être tout simplement accepter cette condition préalable.
Et ne me méprenez pas: j'apprécie votre contribution sur ce sujet.
Ma méthode préférée consiste à créer une interface dans mon unité d'interfaces globales: Cette interface est alors "exposée" dans ma forme principale: la plupart du temps, la mise en œuvre réelle n'est pas sous la forme principale, son juste un support d'endroit et j'utilise le mot clé Implestions pour rediriger l'interface sur un autre objet appartenant à la forme principale. Le point de ceci est que la responsabilité de la configuration est déléguée. Chaque unité ne se soucie pas si la configuration est stockée dans une table, un fichier INI, un fichier XML ou même (gasp) le registre. Ce que cela me permet de faire dans n'importe quelle unité qui utilise l'unité des interfaces globales est un appel comme suit: tout ce qui est nécessaire est d'ajouter des formulaires et mes interfaces globales unité à l'unité que je travaille. Et parce que cela n'utilise pas le formal principal, si je décide de la réutiliser ultérieurement pour un autre projet, je n'ai pas à faire de nouveaux changements ... cela fonctionne simplement, même si le schéma de stockage de configuration est complètement différent. < / p> Ma préférence générale est de créer une table (si je traite une application de base de données) ou un fichier XML. S'il s'agit d'une application de base de données multi-utilisateurs, je vais créer deux tables. Un pour la configuration globale et une autre pour la configuration de l'utilisateur.
+1, parce que je suis d'accord avec la plupart de ce que vous avez écrit et que les différences sont principalement des problèmes de style. Mais la réponse telle qu'elle se trouve n'a pas grand chose à faire avec la question que j'ai comprise comme "quelle est la meilleure façon d'écrire une classe de base capable de se charger et de se stocker au stockage persistant sans avoir besoin de changements de descendants Des classes". C'est au moins la question de la réponse, le titre ne correspond pas à la question de la question. Néanmoins, Smasher devrait suivre votre conseil au lieu d'une solution ini-fichier.
Je veux que ma configuration de configuration prenne aussi peu de temps que nécessaire, car elle est répétée avec chaque application. Pendant que j'aime votre approche dans une certaine mesure, ce n'est pas assez embrassé pour moi. Simple Singleton Global avec Backend XML et une bonne interface pour y accéder est bon dans la plupart des cas. Et plus que suffisant pour les petites applications simples. Même une application entièrement orientée de base de données nécessite toujours un simple fichier de configuration pour accéder à ces données :)
Je suis tout à fait d'accord avec le commentaire de Mghie. Vous proposez une belle alternative à la variable globale à l'aide d'une interface et d'une délégation, mais vous ne dites rien de la manière dont la sérialisation est effectuée. Il ne serait pas de problème d'extraire une iPropertystor de ma solution pour séparer la configuration de la mise en œuvre concrète (fichier INI / xml / base de données). Mais cela ne change pas les points sur le stockage persistant avec un effort minimal.
@gghie: J'ai mis à jour le titre. Je suis d'accord que l'affacturage des trucs ini-file serait bien.
Il y a quelque temps, j'ai écrit une petite unité pour la même tâche - pour enregistrer / charger la configuration d'application dans XML-File.
Vérifiez l'unité Obj2xML.PAS dans notre bibliothèque Freeware SmComponent: http://www.scalabium.com/download/smcmpnt.zip
Nicks Réponse (à l'aide des propriétés Java) a un point: ce moyen simple de lire et de passer la configuration entre les parties de l'application n'introduit pas des dépendances sur une classe de configuration spéciale. Une liste simple de clé / de la valeur peut réduire les dépendances entre les modules d'application et rendre la réutilisation de code plus facile.
dans Delphi, une simple configuration basée sur TRNStrings est un moyen facile d'implémenter une configuration. Exemple: