Winforms: propriétés de classe d'accès à travers l'application

Question

Je sais que cela doit être une question ancienne, fatigué, mais je ne peux pas sembler trouver quelque chose à travers mon ami fidèle (alias Google). J'ai une application .net 3.5 C# winforms, qui présente un utilisateur avec un formulaire de connexion au démarrage de l'application. Après une connexion réussie, je veux courir vers la base de données, récupérer des données spécifiques à l'utilisateur et les conserver (dans les propriétés) dans une classe appelée AppCurrentUser.cs, qui peut être accessible à travers toutes les classes de l'assemblage - le but ici étant que je peux remplir certaines propriétés avec une lecture de données unique, au lieu de faire un appel à la DB chaque fois que je dois. Dans une application Web, j'utilise généralement des variables de session, et je sais que le concept de cela n'existe pas dans WinForms.

La structure de classe ressemble à ce qui suit:

public class AppCurrentUser { 

    public AppCurrentUser() { } 

    public Guid UserName { get; set; } 
    public List<string> Roles { get; set; } 
    public string Firstname { get; set; } 
    public string Lastname { get; set; } 
} 

Maintenant, j'ai quelques options que j'ai besoin des conseils d'experts sur:

être une classe « stupide », je devrais faire les propriétés non static, instanciez la classe puis définissez les propriétés ... mais je ne pourrai accéder à cette instance qu'à partir de la classe dans laquelle elle a été créée, n'est-ce pas?

Logiquement, je crois que ces propriétés devraient être statiques que je ne vais utiliser l'ensemble de l'application classe une fois (et pas créer de nouvelles instances de celui-ci), et ses valeurs de propriété seront « remis à zéro » sur application à proximité. (Si j'en crée une instance, je peux en disposer à la fermeture de l'application)

Comment structurer ma classe et comment accéder à ses propriétés dans toutes les classes de mon assemblage? J'apprécierais vraiment vos conseils honnêtes et précieux sur ceci!

Merci!

Answer 1

Utilisez le singleton ici:

public class AppUser 
{ 
    private static _current = null; 
    public static AppUser Current 
    { 
     get { return = _current; } 
    } 

    public static void Init() 
    { 
     if (_current == null) 
     { 
      _current = new AppUser(); 
      // Load everything from the DB. 
      // Name = Dd.GetName(); 
     } 
    } 

    public string Name { get; private set; } 
} 

// App startup. 
AppUser.Init(); 

// Now any form/class/whatever can simply do: 
var name = AppUser.Current.Name; 

Maintenant, les choses "statiques" sont thread-dangereux. Je vais laisser cela comme un exercice du lecteur pour comprendre comment utiliser correctement la syntaxe lock() pour le rendre thread-safe. Vous devriez également gérer le cas si la propriété Current est accessible avant l'appel à Init.

Answer 2

Cela dépend de la façon dont vous configurez votre architecture. Si vous faites tout votre code de logique métier à l'intérieur du formulaire (par exemple en le couplant à l'interface utilisateur), alors vous voudrez probablement passer des informations utilisateur en paramètre lorsque vous créez un formulaire, puis gardez une référence à l'intérieur de ce formulaire forme. En d'autres termes, vous implémentez un modèle Singleton.

Vous pouvez également utiliser l'injection de dépendances, de sorte que chaque fois que vous demandez l'objet utilisateur, le cadre d'injection de dépendance (comme StructureMap) vous fournira le bon objet. - vous pourriez probablement l'utiliser comme une variable de session puisque vous travaillerez dans un environnement avec état.

Answer 3

L'emplacement correct pour stocker ce type d'informations est dans une implémentation personnalisée de IIdentity. Toutes les informations dont vous avez besoin pour identifier un utilisateur ou ses droits d'accès peuvent être stockées dans cet objet, qui est ensuite associé au thread en cours et peut être interrogé à partir du thread actuel chaque fois que nécessaire.

Cette entité est illustrée dans Rocky Lhotka's CLSA books, ou google winforms l'identité personnalisée.

Answer 4

Je ne suis pas convaincu que c'est la bonne façon mais vous pouvez faire quelque chose comme ça (semble être ce que vous demandez de toute façon):

public class Sessions 
{ 
    // Variables 
    private static string _Username; 

    // properties 
    public static string Username 
    { 
     get 
     { 
      return _Username; 
     } 
     set 
     { 
      _Username = value; 
     } 
    } 
} 

au cas où le C# est faux ... je suis un développeur vb.net ...

alors vous utiliseriez simplement Sessions.USername etc etc