c # – approche pour enregistrer les parameters utilisateur dans une application WPF?

Quelle approche recommandez-vous pour conserver les parameters utilisateur dans une application Windows WPF (bureau)? Notez que l’idée est que l’utilisateur peut modifier ses parameters au moment de l’exécution, puis peut fermer l’application, puis au démarrage de l’application, l’application utilisera les parameters actuels. Effectivement, il apparaîtra comme si les parameters de l’application ne changent pas.

Q1 – Base de données ou autre approche? J’ai une firebase database sqlite que je vais utiliser de toute façon, donc l’utilisation d’une table dans la firebase database serait aussi bonne que n’importe quelle approche?

Q2 – Si firebase database: quelle conception de table de firebase database? Une table avec des colonnes pour différents types de données que vous pourriez avoir (par exemple, ssortingng , long , DateTime etc.) OU juste une table avec une chaîne pour la valeur sur laquelle vous devez sérialiser et désérialiser les valeurs? Je pense que le premier serait plus facile, et s’il n’y a pas beaucoup de parameters, les frais généraux ne sont pas énormes?

Q3 – Les parameters d’application peuvent-ils être utilisés pour cela? Si oui, y a-t-il des tâches spéciales requirejses pour permettre la persistance ici? Qu’adviendrait-il également de l’utilisation de la valeur “par défaut” dans le concepteur d’application dans ce cas? La valeur par défaut remplacera-t-elle les parameters enregistrés entre l’exécution de l’application? (ou devriez-vous NE PAS utiliser la valeur par défaut)

Vous pouvez utiliser les parameters d’application pour cela, l’utilisation de la firebase database n’est pas la meilleure option, compte tenu du temps nécessaire pour lire et écrire les parameters (en particulier si vous utilisez des services Web).

Voici quelques liens expliquant comment y parvenir et les utiliser dans WPF –

Paramètres utilisateur dans WPF

Conseil Quick WPF: comment lier les ressources et les parameters de l’application WPF?

Une fenêtre configurable pour WPF

Vous pouvez stocker vos informations de parameters sous forme de Ssortingngs de caractères XML dans le fichier Settings.Default . Créez des classes pour stocker vos données de configuration et assurez-vous qu’elles sont [Serializable] . Ensuite, avec les outils suivants, vous pouvez sérialiser les instances de ces objects – ou List (ou les tableaux T[] , etc.) de ceux-ci – en Ssortingng . Stockez chacune de ces différentes chaînes dans son propre emplacement Settings.Default respectif dans les Settings.Default de votre application WPF.

Pour récupérer les objects la prochaine fois que l’application démarre, lisez la chaîne Settings intéresse et Deserialize au type T attendu (qui doit être explicitement spécifié comme argument de type pour Deserialize ).

 public static Ssortingng Serialize(T t) { using (SsortingngWriter sw = new SsortingngWriter()) using (XmlWriter xw = XmlWriter.Create(sw)) { new XmlSerializer(typeof(T)).Serialize(xw, t); return sw.GetSsortingngBuilder().ToSsortingng(); } } public static T Deserialize(Ssortingng s_xml) { using (XmlReader xw = XmlReader.Create(new SsortingngReader(s_xml))) return (T)new XmlSerializer(typeof(T)).Deserialize(xw); } 

Je préfère également aller avec la sérialisation à classer. Les fichiers XML correspondent principalement à toutes les exigences. Vous pouvez utiliser le build ApplicationSettings mais ceux-ci ont des ressortingctions et un comportement défini mais (pour moi) très étrange où ils ont été stockés. Je les ai beaucoup utilisés et ils fonctionnent. Mais si vous voulez avoir un contrôle total sur la manière et l’endroit où ils ont été stockés, j’utilise une autre approche.

  1. Créez une classe Quelque part avec tous vos parameters. Je l’ai nommé MySettings
  2. Implémentez Save and Read pour la persistance
  3. Utilisez-les dans votre code d’application

Avantages:

  • Approche très simple
  • Une classe pour les parameters. Charge. Sauvegarder.
  • Tous vos parameters sont de type sécurisé.
  • Vous pouvez simplifier ou étendre la logique à vos besoins (versioning, nombreux profils par utilisateur, etc.)
  • Cela fonctionne très bien dans tous les cas (Database, WinForms, WPF, Service, etc …)
  • Vous pouvez définir où stocker les fichiers XML.
  • Vous pouvez les trouver et les manipuler soit par code ou manuel
  • Cela fonctionne pour n’importe quelle méthode de déploiement que je peux imaginer.

Inconvénients: – Vous devez penser à où stocker vos fichiers de parameters. (Mais vous pouvez simplement utiliser votre dossier d’installation)

Voici un exemple simple (non testé) –

 public class MySettings { public ssortingng Setting1 { get; set; } public List Setting2 { get; set; } public void Save(ssortingng filename) { using (StreamWriter sw = new StreamWriter(filename)) { XmlSerializer xmls = new XmlSerializer(typeof(MySettings)); xmls.Serialize(sw, this); } } public MySettings Read(ssortingng filename) { using (StreamReader sw = new StreamReader(filename)) { XmlSerializer xmls = new XmlSerializer(typeof(MySettings)); return xmls.Deserialize(sw) as MySettings; } } } 

Et voici comment l’utiliser. Il est possible de charger les valeurs par défaut ou de les remplacer par les parameters de l’utilisateur en vérifiant simplement si les parameters utilisateur existent:

 public class MyApplicationLogic { public const ssortingng UserSettingsFilename = "settings.xml"; public ssortingng _DefaultSettingspath = Assembly.GetEntryAssembly().Location + "\\Settings\\" + UserSettingsFilename; public ssortingng _UserSettingsPath = Assembly.GetEntryAssembly().Location + "\\Settings\\UserSettings\\" + UserSettingsFilename; public MyApplicationLogic() { // if default settings exist if (File.Exists(_UserSettingsPath)) this.Settings = Settings.Read(_UserSettingsPath); else this.Settings = Settings.Read(_DefaultSettingspath); } public MySettings Settings { get; private set; } public void SaveUserSettings() { Settings.Save(_UserSettingsPath); } } 

Peut-être que quelqu’un est inspiré par cette approche. C’est comme ça que je le fais maintenant depuis de nombreuses années et j’en suis très content.

L’approche la plus courante de cette question est la suivante: stockage isolé.

Sérialisez votre état de contrôle en XML ou un autre format (particulièrement si vous enregistrez des propriétés de dépendance avec WPF), puis enregistrez le fichier dans le stockage isolé de l’utilisateur.

Si vous souhaitez suivre la voie de paramétrage de l’application, j’ai essayé quelque chose de similaire à un moment donné, bien que l’approche ci-dessous puisse facilement être adaptée pour utiliser le stockage isolé:

 class SettingsManager { public static void LoadSettings(FrameworkElement sender, Dictionary savedElements) { EnsureProperties(sender, savedElements); foreach (FrameworkElement element in savedElements.Keys) { try { element.SetValue(savedElements[element], Properties.Settings.Default[sender.Name + "." + element.Name]); } catch (Exception ex) { } } } public static void SaveSettings(FrameworkElement sender, Dictionary savedElements) { EnsureProperties(sender, savedElements); foreach (FrameworkElement element in savedElements.Keys) { Properties.Settings.Default[sender.Name + "." + element.Name] = element.GetValue(savedElements[element]); } Properties.Settings.Default.Save(); } public static void EnsureProperties(FrameworkElement sender, Dictionary savedElements) { foreach (FrameworkElement element in savedElements.Keys) { bool hasProperty = Properties.Settings.Default.Properties[sender.Name + "." + element.Name] != null; if (!hasProperty) { SettingsAtsortingbuteDictionary atsortingbutes = new SettingsAtsortingbuteDictionary(); UserScopedSettingAtsortingbute atsortingbute = new UserScopedSettingAtsortingbute(); atsortingbutes.Add(atsortingbute.GetType(), atsortingbute); SettingsProperty property = new SettingsProperty(sender.Name + "." + element.Name, savedElements[element].DefaultMetadata.DefaultValue.GetType(), Properties.Settings.Default.Providers["LocalFileSettingsProvider"], false, null, SettingsSerializeAs.Ssortingng, atsortingbutes, true, true); Properties.Settings.Default.Properties.Add(property); } } Properties.Settings.Default.Reload(); } } 

…..et….

  Dictionary savedElements = new Dictionary(); public Window_Load(object sender, EventArgs e) { savedElements.Add(firstNameText, TextBox.TextProperty); savedElements.Add(lastNameText, TextBox.TextProperty); SettingsManager.LoadSettings(this, savedElements); } private void Window_Closing(object sender, System.ComponentModel.CancelEventArgs e) { SettingsManager.SaveSettings(this, savedElements); } 

Outre une firebase database, vous pouvez également avoir les options suivantes pour enregistrer les parameters liés à l’utilisateur

  1. Registre sous HKEY_CURRENT_USER

  2. dans un fichier du dossier AppData

  3. en utilisant le fichier de Settings dans WPF et en définissant sa scope en tant qu’utilisateur

Dans mon expérience, le stockage de tous les parameters dans une table de firebase database est la meilleure solution. Ne vous inquiétez même pas de la performance. Les bases de données actuelles sont rapides et peuvent facilement stocker des milliers de colonnes dans un tableau. Je l’ai appris à mes dépens – avant que je ne me sclérose / désérialise – le cauchemar. Le stocker dans un fichier ou un registre local pose un gros problème – si vous devez prendre en charge votre application et que l’ordinateur est éteint – l’utilisateur n’est pas devant – il n’y a rien à faire … si les parameters sont dans la firebase database – vous pouvez les a changés et alto pour ne pas mentionner que vous pouvez comparer les parameters ….

Je le fais généralement en définissant une classe de parameters [ Serializable ] personnalisée et en la sérialisant simplement sur le disque. Dans votre cas, vous pouvez tout aussi facilement le stocker sous la forme d’un object blob dans votre firebase database SQLite.

  1. Dans tous les endroits où j’ai travaillé, la firebase database était obligatoire en raison de la prise en charge des applications. Comme Adam l’a dit, il se peut que l’utilisateur ne soit pas à son bureau ou que la machine soit éteinte ou que vous souhaitiez changer rapidement la configuration de quelqu’un ou assigner une configuration par défaut (ou membre de l’équipe) à un nouvel utilisateur.

  2. Si les parameters sont susceptibles de croître au fur et à mesure de la publication de nouvelles versions de l’application, vous souhaiterez peut-être stocker les données sous forme de blobs pouvant être désérialisés par l’application. Ceci est particulièrement utile si vous utilisez quelque chose comme Prism qui découvre des modules, car vous ne pouvez pas savoir quels parameters sera renvoyé par un module. Les blobs peuvent être saisis par une clé composite nom d’utilisateur / machine. De cette façon, vous pouvez avoir des parameters différents pour chaque machine.

  3. Je n’ai pas utilisé la classe de parameters intégrée, alors je m’abstiendrai de commenter. 🙂

Je voulais utiliser un fichier de contrôle xml basé sur une classe pour mon application WPF de bureau VB.net. Le code ci-dessus pour faire tout cela en un est excellent et me met dans la bonne direction. Si quelqu’un cherche une solution VB.net, voici la classe que j’ai construite:

 Imports System.IO Imports System.Xml.Serialization Public Class XControl Private _person_ID As Integer Private _person_UID As Guid 'load from file Public Function XCRead(filename As Ssortingng) As XControl Using sr As StreamReader = New StreamReader(filename) Dim xmls As New XmlSerializer(GetType(XControl)) Return CType(xmls.Deserialize(sr), XControl) End Using End Function 'save to file Public Sub XCSave(filename As Ssortingng) Using sw As StreamWriter = New StreamWriter(filename) Dim xmls As New XmlSerializer(GetType(XControl)) xmls.Serialize(sw, Me) End Using End Sub 'all the get/set is below here Public Property Person_ID() As Integer Get Return _person_ID End Get Set(value As Integer) _person_ID = value End Set End Property Public Property Person_UID As Guid Get Return _person_UID End Get Set(value As Guid) _person_UID = value End Set End Property End Class