J'espère que quelqu'un pourra faire la lumière sur les meilleures pratiques pour mon cas d'utilisation.
J'utilise mvvm light et le conteneur simpleIoC dans un wpf usercontrol. J'enregistre mon modèle et y visualise les modèles, le service de données et le service de conception (tout à fait selon l'exemple de code mvvm light)
Les exemples d'utilisation de conteneurs SimpleIoC que j'ai vus semblent toujours traiter le conteneur comme statique / global pour l'espace de noms GalaSoft.
Mais si je crée deux instances de mon contrôle WPF dans la même application, je souhaite bien sûr que chaque contrôle utilisateur ait son propre ensemble de VM et d'instance de modèle. Donc, fondamentalement, son propre ensemble d'instances enregistrées SimpleIoC. Comment pourrais-je y parvenir au mieux lorsque le conteneur IoC par défaut semble être un objet statique?
3 Réponses :
C'est ce que le modèle d'usine est conçu pour résoudre, vous créez une classe qui crée vos modèles de vue de contrôle et vous l'injectez à la place.
Une meilleure séparation des préoccupations également.
merci, pouvez-vous donner un exemple ou une référence? J'ai recherché le modèle d'usine sur Google, mais je ne vois pas comment je peux l'utiliser pour que deux contrôles d'utilisateurs obtiennent leur propre ensemble d'instances de VM et qu'ils obtiennent l'instance correcte en utilisant GetInstance
Comment pourrais-je accomplir cela au mieux lorsque le conteneur IoC par défaut semble être un objet statique?
N'utilisez pas le conteneur par défaut mais créez votre propre instance de la classe
SimpleIoc:Contrôle utilisateur A:
SimpleIoc containerB = new SimpleIoc(); ...Contrôle utilisateur B:
SimpleIoc containerA = new SimpleIoc(); containerA.Register<ViewModel>(); ... ViewModel vm = containerA.GetInstance<ViewModel46>();
Oui, cela fonctionne en partie. Fondamentalement, je peux en effet créer une nouvelle instance du conteneur dans le viewmodellocator et y enregistrer les VM. Mais alors comment faire fonctionner l'injection de dépendances du constructeur?
@Johan. Ça dépend. Comment ça marche actuellement. Et où se situent vos UserControls? Veuillez ne pas poser de questions supplémentaires dans le champ des commentaires une fois que votre question initiale a été répondue.
Cela peut fonctionner, mais d'un point de vue IoC «puriste», cela n'a pas l'air très bien. Je veux dire, créer un nouveau conteneur pour chaque contrôle utilisateur? Je comprends qu'une meilleure approche (usines, portées à vie) peut ne pas être disponible dans SimpleIoc.
Lorsque vous obtenez une instance, vous pouvez éventuellement fournir une clé. Bien que vous obteniez un singleton par type par défaut, cela génère une autre version mise en cache de ce type par clé. Cela signifie que vous pouvez utiliser un guide ou quelque chose comme clé par instance dont vous avez besoin.
Il y a cependant un problème potentiel. Si vous obtenez 100 versions différentes, elles sont toutes en mémoire pendant toute la durée de vie de votre application.
Vous êtes probablement d'accord s'il ne s'agit que de quelques exemples.
Plus et il est probablement préférable d'utiliser un conteneur di plus sophistiqué. SimpleIoC est uniquement destiné à des cas d'utilisation simples.
Vous pouvez cependant utiliser une méthode de fabrique lorsque vous obtenez une instance. Ce n'est pas à mon goût, mais si vous vouliez vraiment utiliser simpleioc, c'est quelque chose à considérer.
Vous pouvez en savoir plus sur laurent bugnion ici.
Merci cela a très bien expliqué. La réponse de Mark Feldman à propos de l'utilisation d'un modèle d'usine est donc simplement de fournir un Guid ou similaire et de générer une instance pour ce Guid. Donc, si j'utilise la méthode d'usine, cette méthode devrait elle-même conserver les instances mises en cache? Semble beaucoup de code pour quelque chose qui "devrait" être facile.
Je pense qu'il suggère d'utiliser l'usine au lieu d'un conteneur di. Et oui. Ce que vous semblez vouloir faire est beaucoup plus facile avec un conteneur di plus sophistiqué. Simple n'est bon que si c'est également suffisant.
La réponse à la question était simplement de créer une instance distincte de SimpleIoC. Cela a résolu mon problème car le VMLocator n'est pas non plus un singleton. Mais j'ai voté pour cet article car il a donné beaucoup plus de détails utiles. Merci!