Con quale frequenza si utilizza il contenitore DI nell'applicazione MV.NET di ASP.NET

5

Durante la lettura di un libro, mi sono imbattuto in DI (dependency Injector) e nel successivo strumento contenitore DI. In precedenza, ho sviluppato un'applicazione seguendo un tutorial sul sito Web di asp.net che non ha mai utilizzato tale strumento. Quindi, la mia domanda può essere riassunta in seguito a due preoccupazioni: -

  • Con che frequenza utilizzi il DI Container?
  • Quali requisiti ti fanno fare così?

MODIFICA: esempi con e senza contenitore DI. Ho scritto i codici per capire quale approccio è migliore.

Senza contenitore DI -

LinqValueCalculator lc = new LinqValueCalculator();
ShoppingCart sc = new ShoppingCart(lc);
decimal total = sc.CalculateStockValue();
Console.WriteLine("Total: {0:c}", total);

con contenitore DI - (in questo esempio viene utilizzato Ninject)

IKernel ninjectKernel = new StandardKernel();
ninjectKernel.Bind<IValueCalculator>().To<LinqValueCalculator>();

IValueCalculator calcImpl = ninjectKernel.Get<IValueCalculator>();
ShoppingCart cart = new ShoppingCart(calcImpl);
Console.WriteLine("Total: {0:c}", cart.CalculateStockValue());

Sarò onesto, sento che scrivere il primo codice era più semplice e naturale. Ma i tuoi punti di vista sono ciò che conta come sto solo imparando il MVC.

    
posta Pankaj Upadhyay 25.09.2011 - 09:00
fonte

3 risposte

9

Quanto spesso utilizzo un contenitore DI?

Molto spesso. Vicino a sempre.

Quali requisiti mi fanno fare così?

In ASP.NET MVC utilizzo sempre un contenitore, perché quando si utilizza l'Iniezione del Costruttore nei Controller si interrompe la convenzione di default di avere costruttori predefiniti. Ciò significa che è necessaria una IControllerFactory personalizzata e, mentre è possibile scrivere e gestirne una a mano, è più lavoro. Utilizzando un contenitore DI che supporta la configurazione basata su convenzione, è possibile utilizzare Iniezione costruttore in modalità basata su convenzione e è richiesta meno manutenzione.

Possiamo fare a meno di loro?

Sì, ma al costo di una maggiore manutenzione del codice dell'infrastruttura: link

    
risposta data 25.09.2011 - 10:11
fonte
4

Possiamo fare a meno di loro?

Sì, ma si perde la capacità di testare facilmente l'applicazione. Prendere in giro i diversi livelli / livelli dell'applicazione è molto più semplice quando si utilizza DI.

Quanto spesso li uso?

Sempre in un'app MVC. StructureMap (per me) ha reso così facile configurare facilmente le convenzioni di default che in realtà non perdo tempo di sviluppo per i guadagni che mi ottengono.

BTW , Faccio DI in questo modo, usando Constructor Injection (semplifica il test delle unità):

public class HomeController : Controller
{
    private readonly IService _service;

    public HomeController(IService service)
    {
        _service = service;
    }

    public ActionResult Index()
    {
        return View(_service.Method());
    }
}
    
risposta data 25.09.2011 - 15:35
fonte
1

Ero solito scrivere un'applicazione C # asp.net con tutte queste best practice in precedenza. DI è molto utile per il linguaggio C #, che è fuori questione. Con una corretta progettazione delle tue classi e interfacce puoi renderlo meno accoppiato e testare / sviluppare più facilmente.

Anno fa sono passato a linguaggi dinamici come Ruby e Python. La mia prima idea era quella di trovare una libreria DI per loro, ma poi ho rinunciato perché mi sono reso conto che DI è un modello perfetto per risolvere problemi di linguaggio statici.

    
risposta data 25.09.2011 - 14:53
fonte

Leggi altre domande sui tag