StructureMap ou DIP manuelle ?

Bonjour,

Dans la meme solution, souvent je vois le melange de StructureMap et de l'injection de dependance manuelle (san Fwk) dans le constructeur/propriete.

Pouvez-vous me dire ce qui justifie l'une ou l'autre utilisation.

Souvent je vois l'injection manuelle dans la DAL, BLL Mais pour la couche web service il y a structureMap.

Merci pour vos conseils.

Tu as un exemple concret ?

Pas d'exemple disponible sous la main.

Juste j'essaye de comprendre ce qui justifie l'utilisation d'un Fwk IoC par rapport au faite de le faire manuellement.

Pour ma part il me semble plus pratique de le faire manuellement en injectant les dependances au constructeur que d'avoir à configuerer un Fwk dans le global.asax.

Alors, pour commencer je précise que je ne suis absolument pas un expert en matière d'IoC, c'est une pratique que je n'ai adoptée que récemment.

En gros, j'utilise un conteneur IoC pour tout ce qui est "services" : des classes dont il existe une seule instance (singleton), qui ont des dépendances entre elles, et dont j'aurai besoin pour toute la durée de vie de l'application.

Par exemple, CommunicationService dépend de ISettingsProvider et éventuellement de quelques autres services, mais pas de données variables, donc le conteneur IoC est bien adapté. L'intérêt est que si je rajoute une dépendance sur un service qui est déjà enregistré auprès du conteneur, j'ai juste à ajouter un paramètre au constructeur, et ça marche tout seul sans avoir à changer autre chose.

Par contre, ça ne convient pas à tous les scénarios : parfois j'ai besoin de créer des instances de classes dynamiquement, en leur passant des paramètres qui sont variables. Je pourrais passer les dépendances explicitement au constructeur, mais ce serait un peu galère, parce qu'il faudrait alors que le code qui crée l'instance ait aussi ces dépendances. Par exemple, si j'ai une classe AlbumViewModel avec un constructeur comme ça :

Code:

---

public AlbumViewModel(Album album, IThumbnailProvider thumbnailProvider)

---

Je ne voudrais pas que la classe AlbumCollectionViewModel qui va instancier des AlbumViewModel ait une dépendance sur IThumbnailProvider, alors qu'elle n'en a pas besoin elle-même...

Dans ce cas là, je crée une factory, qui est enregistrée dans le conteneur IoC et a ses propres dépendances :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public class AlbumViewModelFactory { private readonly IThumbnailProvider _thumbnailProvider;   public AlbumViewModelFactory(IThumbnailProvider thumbnailProvider) { _thumbnailProvider = thumbnailProvider; }   public AlbumViewModel Create(Album album) { return new AlbumViewModelFactory(album, _thumbnailProvider); } }

---

Maintenant AlbumCollectionViewModel a juste besoin d'une dépendance sur AlbumViewModelFactory, et si j'ajoute de nouvelles dépendances, je les ajoute juste à la factory, pas à AlbumCollectionViewModel...

Citation:

---

Pour ma part il me semble plus pratique de le faire manuellement en injectant les dependances au constructeur que d'avoir à configuerer un Fwk dans le global.asax.

---

Bah ça dépend si la conf du conteneur IoC est complexe ou non... Dans mes projets XAML, j'utilise un petit conteneur très simple (il s'appelle d'ailleurs SimpleIoc) inclus dans la lib MvvmLight. La conf est simplissime ; l'enregistrement d'un service via son interface se résume à ça :

Code:

---

SimpleIoc.Default.Register<IThumbnailProvider, ThumbnailProvider>();

---

Et s'il n'y a pas d'interface, c'est encore plus simple :

Code:

---

SimpleIoc.Default.Register<AlbumViewModelFactory>();

---

Donc bon, c'est vraiment pas trop lourd, au vu du temps que ça me fait gagner par la suite...

Merci pour tes explications.

Pour ma part j'utilise le conteneur IoC pour mes Web services qui font appelles à ma couche Business car comme tu l'indiques, je ne passe pas d'instance de classe dynamiquement car toute la partie metier se trouve dans la couche business et non dans les web services. --> Es tu d'accord avec cela ?

Utiliser des factories me parait plutot pas mal en effet.

Je ne comprends pas lorsque tu dis :

Citation:

---

la factory qui est enregistrée dans le conteneur IoC et a ses propres dépendances

---

Citation:

---

public AlbumViewModel(Album album, IThumbnailProvider thumbnailProvider)

---

j'utilisais cela surtout pour ma phase de test unitaire.

Citation:

---

Envoyé par topolino

Pour ma part j'utilise le conteneur IoC pour mes Web services qui font appelles à ma couche Business car comme tu l'indiques, je ne passe pas d'instance de classe dynamiquement car toute la partie metier se trouve dans la couche business et non dans les web services. --> Es tu d'accord avec cela ?

---

Oui

Citation:

---

Envoyé par topolino

Je ne comprends pas lorsque tu dis :

---

Je ne comprends pas très bien ce que tu comprends pas...

La classe AlbumViewModel ne peut pas être créée directement par le conteneur IoC, car elle prend un paramètre qui est dynamique. Donc on fait une factory AlbumViewModelFactory, qui a comme dépendances les dépendances des objets qu'elle doit créer. Puisque AlbumViewModel dépend de IThumbnailProvider, AlbumViewModelFactory a aussi cette dépendance pour pouvoir la passer aux objets qu'elle crée.

oui d'accord pas de soucis, j'avais mal lu sans doute.

Merci à toi.