J'ai constaté que dans beaucoup de cas, il semble (au moins superficiellement) de vouloir utiliser des singletons ou des classes statiques pour les modèles dans mes applications WPF-MVVM. Surtout, cela est dû au fait que la plupart de mes modèles doivent être consultés tout au long de la demande. Faire mes modèles Et pourtant, je suis en conflit parce que tout le monde sur la planète semble détester les singletons. Donc, je me demande, je n'ai pas de meilleure façon, ou si je fais quelque chose de manifestement faux? statique fait un moyen simple de satisfaire cette exigence.
3 Réponses :
Je pense que la solution acceptée à ce problème est d'utiliser l'injection de dépendance. Avec une injection de dépendance, vous pouvez définir vos modèles sous forme de classes régulières, non statiques, puis d'inversion du conteneur de contrôle "injecter" une instance de votre modèle lorsque vous le souhaitez.
Il y a un bon tutoriel sur wpftorial.net qui montre comment faire une injection de dépendance dans WPF: http: // wpfttucial .NET / REFERENCEARCHITECTURE.HTML
Intéressant. J'ai commencé à apprendre Di quelques semaines. On dirait que je vais choisir ça en arrière. Merci.
Il y a quelques problèmes avec des singletons. Je vais les décrire ci-dessous, puis proposer des solutions alternatives. Je ne suis pas un "N'utilise jamais un singleton, ni tu es un codeur de merde" genre de gars comme je crois qu'ils ont leurs utilisations. Mais ces utilisations sont rares.
Sécurité du fil. Si vous avez un Singleton Statique global, il doit s'agir de la sécurité thread-coffre-fort, car tout peut y accéder à tout moment. C'est des frais généraux supplémentaires.
Le test unitaire est plus difficile avec les singletons.
C'est un remplacement bon marché pour les variables globales (je veux dire, c'est ce qu'un singleton est à la fin de la journée, bien qu'il puisse avoir des méthodes et d'autres objets de fantaisie).
Voir, ce n'est pas que Singleton est "des abominations horribles" en soi, mais que c'est le premier modèle de conception de nombreux nouveaux programmeurs à traiter et que sa "commodité vomise ses" pièges (coller juste des vitesses dessus et l'appeler Steam-punk).
Dans votre cas, vous parlez de modèles et ce sont toujours des "instances" car ils reflètent naturellement les données. Peut-être êtes-vous inquiet du coût d'obtenir ces instances. Croyez-moi, ils devraient être négligeables (à la conception d'accès à des données, évidemment).
SO, Alternatives? Passez le modèle aux endroits qui le nécessitent. Cela facilite le test de l'unité et vous permet d'échanger les fondamentaux de ce modèle dans un cœur de cœur. Cela signifie également que vous voudrez peut-être consulter les interfaces - celles-ci dénote un contrat. Vous pouvez ensuite créer des objets concrets qui implémentent ces interfaces et voilà - votre code est facilement testable et modifiable.
Dans le monde singleton, un seul changement à ce singleton pourrait fondamentalement tout briser dans la base de code. Pas une bonne chose.
Agréable. Je dirais même: N'utilisez jamais singleton à moins que vous n'ayez pas un autre choix.
La seule classe statique que j'utilise est un MessageBroker car j'ai besoin de la même instance dans l'application.
Mais même il est très possible d'utiliser l'unité (ou une autre injection de dépendance / conteneur) pour gérer des instances de classes que vous n'avez besoin que de l'une des.
Cela vous permet d'injecter différentes versions lorsque cela est nécessaire (par exemple pendant les tests d'unité)
BTW: statique n'est pas la même chose que Singleton. Mais je ne suis pas dans ça ici. Il suffit de rechercher Stackoverflow pour des questions plus amusantes à ce sujet :)
Faire des "modèles" statique ?? Non, pas vraiment. Pas même un peu. C'est encore pire que analyse HTML avec regex
Il h. Ne pouvait pas résister je vois.
Si vous utilisez DI, au lieu de la rendre statique, enregistrez-la dans le conteneur avec le conteneur -TrolledlifetimeManager. Avec statique, vous avez plus d'un problème de sécurité du fil.