Questions StructureMap 2.6.1 et ASP.NET MVC 2 (d'un débutant complet dans DI)

Question

Par une conversation avec @Aaronaught sur un autre thread, j'ai commencé à convertir mon application pour utiliser l'injection de dépendances et les modèles de référentiel, mais je suis un peu coincé. Je pense que je reçois la plupart des choses et le flux des modèles, mais je suis bloqué sur l'implémentation de StructureMap dans ASP.NET MVC 2. Les exemples que j'ai lus semblent être obsolètes avec la dernière version de Structure Map que je J'utilise (2.6.1).

J'espère que quelqu'un peut combler les lacunes en fonction du code ci-dessous je coller:

public static class Bootstrapper { 
    public static void Configure() { 
     ObjectFactory.Configure(x => { 
      x.For<DataContext>().Add(new DataContext()); 
     }); 
    } 
} 

Avec ce que je peux obtenir une instance de DataContext à partir de mon contrôleur (s) avec:

Je sais que c'est faux de le faire, mais je suis confus sur la façon de l'éviter.

protected DataContext dc = ObjectFactory.GetInstance<DataContext>(); 

Sur la route, voici l'usine du contrôleur:

public class StructureMapControllerFactory : DefaultControllerFactory { 
    protected override IController GetControllerInstance(
     RequestContext rc, 
     Type ct) { 
     return (ObjectFactory.GetInstance(ct) as Controller); 
    } 
} 

Je ne comprends pas exactement ce que cela fait, mais il est dans les exemples, donc je le reproduire. Quelqu'un peut-il me l'expliquer? Maintenant, d'après ce que je comprends, il est censé y avoir des registres qui, si je comprends bien, globalisent des instances d'objets telles que DataContext. Est-ce exact? Si oui, comment puis-je écrire le registre de StructureMap 2.6.1? L'exemple de code que j'ai vu semble obsolète parce que quand je l'écris je n'ai pas les mêmes options à ma disposition (via IntelliSense), donc je ne sais pas comment l'écrire ...

Je vais vraiment apprécie toute aide pour combler les lacunes que j'ai.

P.S. Mon expérience avec Dependency Injection and Repositories est d'environ 8 heures au total.

MISE À JOUR/CONCLUSION

Après avoir lu par @ excellente explication de pure ci-dessous et en regardant la vidéo tekpub il a fait référence dans un sous-commentaire que j'ai opté pour Ninject sur StructureMap.

Je ne sais pas si Ninject est meilleur que StructureMap, mais de mon point de vue, c'est vraiment beaucoup plus facile de commencer et d'y aller.

Answer 1

OK,

Je suis sûr que Jeremy Miller corrigera mon post et vous donner la vérité, mais l'idée d'avoir cette coutume Controller factory qui utilise StructureMap pour créer les contrôleurs, est parce que la Controller class est la clé où la majorité de la logique démarre et a lieu (Oui, il y a des filtres d'action et des choses qui se passe avant, mais gardons cela simple) - et cela doit avoir toutes les dépendances pré-configurées avant que toute logique commence.

Donc, l'idée est la suivante. Si toutes les choses de la logique et de la magie-licorne se produisent dans les méthodes Controllers, alors quand nous commençons d'abord entrer la méthode ... nous devons avoir toutes nos exigences déjà installées. Plus important encore, chaque méthode dans n'importe quel contrôleur ne devrait pas se préoccuper de ce que l'exigence (c.-à-instances) il a .. juste que quelqu'un, de quelque part. .. a déjà pris cette décision et m'a donné tous les objets importants que nous pourrions exiger.

Ceci est au cœur de ce qu'est DI/IoC.

Alors utilisons un code très simple pour expliquer cela, parce que je ne suis pas bon pour expliquer les choses.

---

laisse supposer que nous avons la méthode suivante dans le contrôleur: -

public ActionMethod Index() 
{ 
    // List all Products. 
} 

assez simple. Listes juste quelques produits au navigateur. Donc, la première chose que vous devez demander est -> quelles sont Products? d'où viennent-ils? Eh bien, la méthode du contrôleur ne pose pas cette question du tout. En fait, il ne prend pas soin où ils venaient. Il se soucie seulement qu'il a quelque chose qui est un Product. Donc, quand nous sommes dans cette méthode, nous ne devrions pas nous soucier de l'endroit où les informations sur le produit existent. Nous voulons juste faire quelque chose avec ces choses appelées Products '.

Ok .. permet donc de faire quelque chose avec elle ...

public ActionMethod Index() 
{ 
    var products = _myProductService.Find().ToList(); 

    // .. rest snipped. 
} 

Ok .. Jusqu'à présent, nous demandons maintenant un service pour trouver tous les produits et les énumérer. Kewl. Pourtant, nous ne nous soucions pas d'où ces produits proviennent. Ou même, qu'est-ce que c'est Product Service. C'est la clé ->Nous laissons le DI/IoC à s'inquiéter à ce sujet. Tout ce qui nous intéresse, c'est le fait que nous avons quelques ProductService qui font des choses avec certains produits. Dans ce cas, il va Find tous les produits et nous lui demandons de lister tous les produits, trouvés.

Alors, où DI/IoC entrent en jeu?

Ceci est la partie licorne magique :)

Lorsque ce contrôleur était instancié, il a demandé StructureMap:!

« Oi StructureMap Je dois créer un HomeController Mais le. HomeController a au moins un constructeur .. et le constructeur le plus complexe qu'il a (note: DI/IoC appellent cela le plus gourmande constructeur) liste un nombre d'objets dont il a besoin. Alors ... Je besoin de créer ces objets d'abord, puis créer mon HomeController .. et passer ces objets in.pass ces objets.

permet de regarder le code ...

public class HomeController : Controller 
{ 
    private IProductService _productService; 
    private ILoggingService _loggingService; 

    public HomeController(IProductService productService, ILoggingService loggingService) 
    { 
     _productService = productService; 
     _loggingService = loggingService; 
    } 

    public ActionMethod Index() 
    { 
     var products = _productService.Find().ToList(); 

     // rest snipped. 
    } 
} 

whoa - il y a quelques choses qui se passent ici. Permet de récapituler -> Alors StructureMap dit:

je besoin d'une instance d'un IProductService et un ILoggingService .. que je passe au constructeur HomeController ... u peut me donner les s'il vous plaît?"

Et StructureMap dit alors:..

Ok .. premier up -> un IProductService permet de voir ici, U've attaché un IProductService à une classe personnalisée que vous avez fait, appelé ReallyFastProductService Kewl , je vais créer un de ces mauvais garçons Ensuite, vous avez mappé un ILoggingService à une classe NLogLoggingService ... agréable! NLog wroxs, mec Donc, je vais aussi créer un de ces mauvais garçons. Voici maintenant deux exemples: Enfin, je peux maintenant faire une instance du HomeController que vous recherchez .. et ensuite je vais passer ces deux objets que je viens de faire, dans le constructeur HomeController ... et l'alto! voici l'instance du contrôleur.

... alors maintenant, vous avez l'instance de contrôleur.

.... et quand vous entrez dans la méthode Index(), si vous utilisez la souris et survolez les instances, elles seront ReallyFastProductService et NLogLoggingService.

Génial! Cela signifie donc que la méthode Index() n'est jamais étroitement couplé à une implémentation particulière d'une classe.

Maintenant, vous avez décidé que vous n'avez pas aimé tout le code que vous avez fait dans le ReallyFastProductService et avez décidé d'en coder un autre, qui utilise de nouveaux trucs et compétences que vous venez de ramasser. Alors maintenant vous faites une 2e classe appelée, PewPewProductService, parce qu'elle pwns. Maintenant, si u changer votre StructureMap de cartographie ...

ObjectFactory.Configure(x => 
    { x.For<IProductService>().Add(new ReallyFastProductService());}); 

à

ObjectFactory.Configure(x => 
    { x.For<IProductService>().Add(new PewPewProductService());}); 

... tout à coup, toutes les méthodes qui HomeController se réfèrent désormais à la logique de la nouvelle classe que vous venez de construire . Pas besoin de changer de code dans le contrôleur.

Catch the penny comme il tombe :)

Bienvenue sur DI/IoC et pourquoi il kicks butt sérieux.