C'est vraiment déroutant pour moi. Rien ne nous empêche de créer une classe avec des champs d'instance et Méthodes d'instance, contre la création d'une classe avec des champs statiques et des méthodes statiques. Les deux peuvent être enregistrés comme un singleton.
Y a-t-il une approche préférée de ce problème et pourquoi?
edit: Je ne demande pas de créer une classe à l'aide du modèle singleton. Je demande à propos de la dépendance singleton injectant une classe par rapport à l'injection de la même classe mais avec des membres / champs définis statiques / méthodes / propriétés.
3 Réponses :
Vous devez comprendre les différents Lifetimes pour DI et vos besoins, afin de choisir la durée de vie appropriée.
En cas de doute, faites-le transitoire.
Je suppose que sa valeur ne devinait à mentionner que si vous créez des services comme transitoires et qu'ils ont des propriétés statiques que vous modifiez constamment, cela affectera toutes les autres instances créées, car STATIC affecte le type lui-même, plutôt qu'une instance.
Je suis au courant des vies. Je demande une chose complètement différente. Quelle est la différence entre un objet injecté en tant que singleton qui n'a pas de champs statiques / propriétés / etc., contre injectant le même objet qu'un singleton, mais ayant des champs statiques / propriétés / etc.
Je vous demande [...] injecter la même classe mais avec des membres statiques définis / champs / méthodes / propriétés
c'est possible mais inutile. Si un contrôleur nécessite un tel objet singleton
objet , vous avez toujours Aucune instance méthode pour appeler sur cet objet. Votre contrôleur doit appeler des méthodes statiques sur la classe. [...] Création d'une classe avec des champs d'instance et des méthodes d'instance
C'est une meilleure façon de le faire car cela vous permettra de vous moquer de l'objet pour des tests d'unités.
Si vous voulez un exemple concret, j'ai codé un classe avec des méthodes d'instance pour stocker des données sur les utilisateurs, qui est enregistré comme un objet singleton et utilisé dans le contrôleur .
J'espère que cela rend les choses plus claires pour vous.
Est-ce que ça va s'il utilise des champs privés statiques en lecture seule à ses fins alors? Ou devraient-ils être rendus non statiques?
@Spiritbob pouvez-vous être plus précis? Voulez-vous dire: est-il possible que l'objet Singleton utilise des champs statiques de sa propre classe? Oui c'est possible. Il vaut mieux les rendre privés afin que les classes externes ne puissent pas faire référence à ces champs statiques. Les classes externes ne doivent utiliser que l'objet Singleton. Le plus important est de vous assurer que votre objet Singleton est le fil-en-santé, car une application ASP.NET CORE gère des demandes Web simultanées . C'est pourquoi j'utilise une serrure dans mon exemple lorsque vous pour lire / écrire un Ressource partagé, par exemple la liste qui stocke la liste d'utilisateurs
Les champs de classe statiques peuvent être modifiés par d'autres cas de la même classe. En enregistrant une classe comme singleton avec des champs statiques, vous compterez sur le fait que jamais dans aucune autre partie de l'application, aucune autre instance de la même classe ne sera créée.
Je me rends compte que vous vous concentrerez sur l'obtention d'une instance de DI-Toutefois, si n'importe où dans l'application, une instance anohter de point de la classe est instanciée directement et non via DI - la propriété statique sera exposée à un changement potentiel de IT State (valeur).
Utilisation des propriétés d'instance Singleton / Champs vous permettra de travailler uniquement avec les propriétés / champs contrôlés par l'instance que vous obtenez de DI.
Est-ce que cela répond à votre question? Différence entre classe statique et modèle singleton?
Auriez-vous même besoin de di pour la classe statique?
@Joeh Si vous introduisez un constructeur avec d'autres services - ouais vous faites. Sinon, la mise en œuvre concrète devrait utiliser des classes concrètes.