Ktery IoC/DI kontejner v .NET 4.0? rubrika: Programování: .Net

9 Honza Břešťan
položil/-a 28.1.2013
 
upravil/-a 28.1.2013

Rozhodl jsem se zkusit zavest do projektu IoC/DI a protoze pro .NET existuje hned nekolik rozsirenych kontejneru, tak nevim, ktery pouzit. Jedna se o vetsi projekt, kde jde i o performance (vytvareni instanci je casto "hladove" i bez DI, treba Couchbase clienti).

Zatim mam nasledujici kandidaty:

  • Unity
    • + MSDN dokumentace a dalsi vyhody ofic MS produktu
    • + Tooling podpora - Visual Studio? (Je vubec nejaka? Casto u MS veci byva)
    • - Dalsi vyvoj? (MS rad zahazuje rozdelane veci)
    • - Vykon?
  • Castle Windsor
    • + Videl jsem na GeekCore a melo to hlavu a patu
    • + Siroce pouzivany
    • - XML Konfigurace
    • - Vykon?
  • Ninject
    • + Minimalisticky a udajne rychly
    • + Open-Source
    • + Pluginovatelny
    • - ???
  • "DI by hand"
    • + Nulova ztrata performance
    • + Zadna zavislost na kontejnerech
    • - Pracnost
    • - Managovatelnost

Nejlepe vychazi asi Ninject, zatim jeho studiu venuji nejvic casu.

Mate nekdo vic zkusenosti? Prehledl jsem neco, nebo neco proste neni pravda? Co byste doporucili pro snadnou integraci s existujicim projektem?

Diky vsem.

Komentáře

  • Pavel Hodek : Zajímavý je také Autofac (http://code.google.com/p/autofac/). Sám se rozhoduji mezi ním a Ninject. 30.1.2013
  • Filip Kinský : Windsor "- XML Konfigurace" jsi myslel jak presne? Jako ze ji nema nebo ze ma jen XML konfiguraci? :) Windsor ma krasne C# fluent registracni API a zaroven umoznuje pouzit i XML. O vykon bych se taky u nej nebal - pouzival jsem ho i na hodne velikych projektech bez nejmensich problemu. Za mne je Windsor jasna volba - ma spoustu extension pointu a zadny vyrazny negativa. 8.2.2013
odkaz
Anonym
odpověděl/-a 11.2.2013
 
upravil/-a 11.2.2013

Osobně jsem velmi vybíravý a tak jsem si před lety vybral Castle.Windsor a do dnešního dne jsem neměl důvod na tuto volbu nadávat. Windsor je dospělým IoC kontejnerem, který je široce používaný a hlavně věci dávají logiku, nenutí nás psát spoustu zbytečného kódu a jeho architektura umožňuje snadno rozšiřovat schopnosti kontejneru nebo upravovat chování/konvence dle vlastních potřeb. Ale ve většině případů to není potřeba, protože autoři při návrhu používali mozek a sami používají Windsor.

Pár bodů, které považuju za zásadní výhody:

  • Fluent konfigurace umožňuje registraci na základě konvencí a tam kde je to potřeba doladit konkrétní detaily.
  • Nikde nemusím explicitně bindovat nebo routovat závislosti nebo vyjadřovat jejich typy.
  • Nejsem nucen ve svém kódu používat speciální anotace, interfejsy nebo jiné konstrukce, aby něco fungovalo, jak si představuje kontejner.
  • Facilities jsou ohromným pomocníkem. Práci s WCF bych si třeba nedokázal bez WCF Facility představit. To platí i pro NHibernate.
  • Windsor obsahuje velice mocnou diagnostiku a na případné problémy nás upozorní nebo doporučí lepší postup.
  • Vyhazované výjimky obsahují návodné popisy, které nejen popisují v čem je problém, ale také dávají rady, jak problém vyřešit.
  • Pokud máte nějaký problém, najdete odpověď buď ve skvělé a udržované dokumentaci nebo i na stackoverflow vám lidé správně odpovědí celkem rychle (sám se o to snažím) a v neposlední řadě existuje spousta tutoriálů a pokročilých technik na blozích.

Podobně vyspělým kontejnerem je ještě StructureMap, který má i některé featury, které Windsor nemá. Ale Windsor je nemá, ne proto, že by to nešlo, ale protože tyto postupy nejsou čisté. A to považuju za největší plus Windsoru, pokud se budete držet návodů, dokumentace a doporučení na SO, vaše architektura bude mnohem čistší. Někdo se může snažit nasadit argumentaci, že třeba Funq je za běhu 25x rychlejší. Co je to platné, když práce s ním je procházkou v lambda hell plnou explicitního vyjadřování zřejmých věcí?

Pro zobrazení všech 7 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.