Je veux refacturer un certain code à l'aide du cadre Windsor IOC / DI, mais mon problème est que j'ai des classes de singleton et des classes d'usine et je ne suis pas sûr que l'on puisse implémenter un singleton ou une usine à l'aide de DI.
Quelqu'un a-t-il des idées si cela est possible et comment?
3 Réponses :
Vous ne le faites pas, vous laissez le conteneur du COI le faire. Où Avant d'avoir des appels explicites sur une usine pour obtenir une instance Singleton d'un objet, vous disposez maintenant du conteneur COI de créer un graphique d'objets pour vous et que tout ce qu'elle appartient. Le conteneur s'assure que vos singletons sont des singletons et sert d'usine.
Si vous parlez d'une usine décider au moment de l'exécution Quel type d'objet servir, DI n'est pas applicable là-bas, sauf que vous puissiez disposer du conteneur DI injecter l'usine où vous le souhaitez et gérez sa portée.
Le cadre du CIO n'a-t-il pas non plus la capacité de décider de l'objet à servir au moment de l'exécution? Alors pourquoi utiliser une usine de cette façon lorsque vous utilisez di? J'utiliserais davantage une usine pour créer plusieurs instances des mêmes classes ...
Je veux dire lors de l'utilisation du CIO, pas "en utilisant di"
Généralement, les cadres IOC sont jolis statiques, ils créent des objets pour vous en fonction de la configuration (XML, des annotations, des fichiers de propriété, quoi que ce soit), donc non, il n'y a pas grand-chose de décider quoi créer à la volée.
Le modèle de conception singleton est en désaccord avec DI. Bien qu'il soit possible d'ouvrir un singleton tellement que di et le Principe ouvert / fermé commence Pour avoir du sens, cela changera tellement le singleton qu'il cesse presque d'être un singleton.
Le fil de la sécurité est un gros problème qui me vient à l'esprit lorsque vous commencez à ouvrir un singleton.
Il est bien préférable de définir simplement vos services et vos cours sans trop tenir compte de leur portée. Si vous avez un objet que vous souhaitez partager entre plusieurs consommateurs, la plupart des conteneurs DI ont le concept d'un Singleton Lifetime , qui imite les avantages du modèle de conception singleton sans souffrir de l'un des inconvénients.
En bref: les singletons sont diaboliques et doivent être évités.
abstrait usine , d'autre part, est très utile pour des objectifs di.
Singletons est quelque chose que j'utilise assez souvent, mais lisez ceci, il semble que je vais devoir changer ma stratégie! Je les ai trouvés à être très utile dans certaines situations ... mais je peux voir où vous venez de la sécurité du fil.
La sécurité du fil est une chose, mais le problème principal est la violation du principe ouvert / fermé.
Si j'utilise un conteneur di conteneur pour gérer la portée d'un singleton pourquoi est-ce une violation de OCP? Parce que je ne repose pas sur des méthodes statiques pour la mise en œuvre, je peux toujours le sous-classement, je penserais que l'utilisation d'un conteneur di conteneur pour singletons me permet de préserver OCP. ?
Si votre conteneur DI implémente une interface et qu'il s'agit simplement d'être un singleton, alors il ne violera pas OCP - il n'est qu'un détail de mise en œuvre. Le danger réside dans le fait que puisque c'est un singleton, il est disponible partout, un développeur inexpérimenté peut donc l'utiliser directement et créer par inadvertance un couplage serré.
L'utilisation courante de singletons (par opposition à les utiliser pour des choses comme des piles de vol, etc.) et les deux résolvent tous deux le même problème - l'emplacement d'une dépendance requise. Essayer de les combiner est inutile, car vous finissez par résoudre le même problème deux fois. Il suffit d'utiliser di - ça vous donnera plus de flexibilité à long terme.
La plupart des cadres d'injection de dépendance modernes vous permettent de spécifier s'ils doivent servir une instance d'objet unique pour la durée de vie de l'application (ou de la demande) ou de créer de nouvelles instances à chaque fois que vous demandez un.
Vous pouvez également utiliser un cadre DI pour résoudre les dépendances sur les usines lorsqu'il est approprié (si c'est ce que vous voulez dire). Vous pouvez le faire si l'usine sélectionne une sous-classe basée sur des données d'exécution, ou si un objet dépendant doit créer plusieurs instances ifoo , auquel cas vous pouvez injecter un ifoFoFactory .
Je veux dire ce dernier point de créer de nombreuses instances d'une certaine classe à l'aide d'une usine, puis à injecter l'usine dans une classe.