J'ai une application qui utilise SQLite, qui est extrêmement légère et rapide. J'ai des préférences qui n'ont pas nécessairement besoin d'être chargées au démarrage, mais elles devraient être utilisées à divers moments en fonction de l'endroit où l'utilisateur va. Cela étant dit, je ne peux pas décider où stocker ces informations.
Q1: Devrais-je simplement aller de l'avant et le stocker dans la base de données? Devrais-je le stocker dans un fichier de configuration?
Q2: Devrais-je charger et stocker les préférences et autres données au démarrage, même si elles ne sont pas nécessairement utilisées immédiatement? Ou devrais-je simplement interroger la base de données quand j'en ai besoin?
Exemple: Mon application peut stocker les informations de la société pour la société qui utilise le logiciel. Nom de la société, téléphone de la société, etc. La seule fois que ces informations sont utilisées se trouve lorsque le logiciel imprime automatiquement une lettre ou l'utilisateur va modifier les informations de leurs entreprises dans le programme.
Edit: J'ai réalisé que cela revient aux paramètres de l'application VS Paramètres utilisateur. Mon programme n'a pas de multiples utilisateurs par copie du logiciel. Cela étant dit, je suppose que celles-ci seraient des paramètres d'application.
4 Réponses :
Combien de paramètres cherchez-vous à économiser? L'utilisation de la fonctionnalité de paramètres intégrée est assez indolore.
Pas trop du tout. Jamais entendu parler de cela ... je vais lui donner une lecture.
Je ne recommanderais pas cela pour les paramètres "utilisateur", uniquement les paramètres "Application". Si vous utilisez des paramètres "utilisateur", les valeurs sont stockées dans le dossier AppData dans un nom de fente bizarre qui change pour chaque version de l'application le rendant ainsi que si les mises à niveau des utilisateurs, tous les paramètres précédents disparaissent.
J'ai réalisé que cela revient aux paramètres de l'application VS Paramètres utilisateur. Mon programme n'a pas de multiples utilisateurs par copie du logiciel. Cela étant dit, je suppose que celles-ci seraient des paramètres d'application. Dans ce cas, je suppose que la réponse de la JTA serait la meilleure pour mon problème. Si quelqu'un a une raison pour laquelle cela ne serait pas si, s'il vous plaît laissez-moi savoir!
@Chris Thompson Nous avons rencontré cela en mettant un dossier "partagé" dans l'Appdata qui conserve les paramètres des utilisateurs (il s'agissait d'un piratage en utilisant log4net pour créer le répertoire lors de la première exécution de l'application); De cette façon, même s'ils mettent à niveau, leurs paramètres restent autour. Nous déplaçons actuellement cela dans une base de données pour d'autres raisons (chargez-vous équilibré RemoteApp).
Un autre commentaire. L'application elle-même ne peut pas modifier les paramètres stockés comme paramètres de l'application à l'aide de la classe de paramètres intégrée. Assurez-vous donc que tous les réglages que vous stockez sont prêts à faire manipuler votre fichier XML directement.
Du lien donné: "La distinction cruciale entre la portée de l'application et les paramètres d'application de l'utilisateur est que les paramètres d'application de l'utilisateur sont en lecture / écriture au moment de l'exécution et que leurs valeurs peuvent être modifiées et enregistrées en code. Les paramètres d'application sont en lecture seule. à l'exécution." Je suppose que je vais devoir les spécifier comme paramètres de portée utilisateur, même s'ils ne le sont pas.
stocker les données de configuration dans un fichier est bon pour les paramètres légers qui changent rarement. Habituellement, vous le feriez pour les paramètres différents entre le développement et la production et sont utilisés pour faire fonctionner votre application.
Après cela, tout le reste est mieux stocké dans une base de données. Cela vous donne la possibilité d'utiliser de bonnes interfaces utilisateur pour modifier les paramètres, chargez-les en cas de besoin, enregistrez-les lors de la mise à niveau de votre système, être disponible si vous utilisez plusieurs extrémités frontales (par rapport à la sauvegarde de la configuration dans un fichier et assurez-vous à tout le front. -Fend les mêmes fichiers à jour.)
Ce que vous voudrez peut-être faire est d'écrire une classe qui encapsule les paramètres, puis les lit dans HASHTABLE.
Vous pouvez avoir une méthode de getSetage de base qui recherche un paramètre basé sur un nom. Si le réglage est situé dans la haquetable, renvoyez la valeur, sinon accédez à la DB pour trouver le réglage, puis rangez-la dans la haquetable. Vous pouvez ensuite écrire des propriétés séparées pour chaque paramètre souhaité, chacun appelant les méthodes de rencontre / setsetting.
Ceci vous permet de stocker les paramètres de la DB facilement et de cache les lectures pour éviter de lire constamment la DB. puis créer une classe avec un tas de propriétés telles que ceci: Vous pouvez maintenant le faire dans votre Code:
J'apprécie votre explication approfondie et vos exemples de code, mais comme mon commentaire indique au-dessous de la poste de JTA, je pense que je serais mieux adapté pour utiliser sa solution que mes paramètres seraient des paramètres d'application.
En plus de la réponse JTAS, je voudrais ajouter que j'ai utilisé 3 méthodes et elles ont tous leurs côtés de haut en bas.
Les stocker dans la base de données est utile si vous ne voulez pas que ce soit lié à un utilisateur mais plutôt à la base de données. Bien que vous ne puissiez pas changer ces paramètres de l'extérieur de l'application.
J'ai utilisé une classe de configuration que je Serialize avec XML si j'ai besoin de modifier avec un éditeur XML. Par exemple Ceci est très utile si vous êtes exécuter un service.
Chargement en cas de besoin La première fois que le chargement sur l'application commence est une préférence personnelle. Chargement lorsque cela est nécessaire pour une heure de début plus rapide. Singleton recherche comme ça (où vous le chargez dans un singleton sur le premier accès) sont un impact négligeable, mais peut avoir un effet d'interface utilisateur défini. Examinez comment Photoshop chargea (où il charge tout avant de vous donner l'interface utilisateur) par rapport à la pause que vous obtenez dans certaines applications lorsque vous chargez des choses et obtenez cet écran d'attente ennuyeux.
@DrachenSystem et vous pouvez également charger les choses en arrière-plan et laisser l'utilisateur à attendre qu'il charge s'il n'est pas chargé. Beaucoup comme Visual Studio. Parfois, le cache de documentation n'est pas construit, mais si besoin
Très vrai, mais pour la plupart, les données que je vais charger est de très petite taille, l'utilisateur ne doit même pas remarquer.