Laden...

Welchen IoC-Container benutzt ihr?

Erstellt von serial vor 13 Jahren Letzter Beitrag vor 13 Jahren 4.240 Views
S
serial Themenstarter:in
902 Beiträge seit 2007
vor 13 Jahren
Welchen IoC-Container benutzt ihr?

Hallo,

mich würde interessieren, welche DI-Container ihr so benutzt, und warum.
Solltet ihr mehrere Container benutzen, schreibt bitte welche es sind, und in welchen Fällen entscheidet ihr euch für den einen oder den anderen?

Solltet ihr einen ganz anderen als in der Liste vorhandenen einsetzen, interessiert mich, welcher es ist.

Interesse habe ich auch an euren Meinungen bzw Vor-und Nachteilen der/des von euch eingesetzen DI-Container/s.

mfg
serial

F
10.010 Beiträge seit 2004
vor 13 Jahren

In eigenen Projekten benutze ich Hiro, oder Unity.

Beruflich benutzen wir CAB also benutzen wir dort ObjectBuilder, also sozusagen den Vorgänger von Unity.

161 Beiträge seit 2007
vor 13 Jahren

Castle Windsor.
Für WP7 verwende ich atm noch ninject.

Es drängt sich mir die Frage auf, wie man "keinen DI Container" benutzen kann...

"Eine wirklich gute Idee erkennt man daran,
dass ihre Verwirklichung von vorneherein ausgeschlossen erscheint."
(Albert Einstein)

B
20 Beiträge seit 2010
vor 13 Jahren

Wir benutzen auch CAB auf arbeit.. weil es uns viel arbeit abnimmt 😃

F
240 Beiträge seit 2006
vor 13 Jahren

Managed Extensibility Framework. Die Attribute sind der Hammer 😃

1.044 Beiträge seit 2008
vor 13 Jahren

Hallo Femaref,

bevor deine Aussage jetzt in einer Diskussation ausharrt, möchte ich mich kurz fassen MEF : Dependency Injection Framework oder nicht. In diesem Beitrag findest du alle nötigen Informationen.

Kurz und knapp: MEF gehört nicht dazu.

zero_x

F
240 Beiträge seit 2006
vor 13 Jahren

Wenn man den Post zur Hand nimmt, dann ist aber schon die Fragestellung im ersten Post inkonsistent zur Überschrift 😉

Ich würd trotzdem gern eine Antwort dazu setzen.

Und zwar gestaltet sich meine Benutzung aktuell zwar noch im Rahmen der DI/IoC ("So while MEF can be used for composition, that's merely a small intersection of its capabilities relative to other IoCs", MEF (Managed Extensibility Framework) vs IoC/DI), aber da ich in Zukunft plane, Plugins zuzulassen, wird mir MEF da gut helfen können.

Okay, das war die technische Erklärung... der eigentliche Grund ist aber eher, dass es die erste DI/IoC Implementierung war, die mir beim Verständnis sehr geholfen hat. Erst dadurch habe ich wirklich gelernt, in DI zu "denken". Ich hatte zuvor sowohl Castle Windsor als auch Hiro versucht, was aber nicht auf Anhieb funktioniert hat. MEF dagegen war in der WAF Doc als Beispiel benutzt, und da ich da zuerst mit DI richtig in Berührung kam, habe ich es übernommen.

Ganz klar, es fehlt eine Configuration, die Assemblies werden bei jedem Startup gescannt, dadurch ist es schwer, den Dependency Tree wirklich zu testen. Ist neben der höheren Startupzeit gewiss ein Nachteil, ich denke aber, dass es sich mit den Vorteilen im Plugin Bereich definitiv lohnt.

Wenn du es weiter diskutieren möchtest, kannst du mir gerne eine PM schreiben.

1.044 Beiträge seit 2008
vor 13 Jahren

Hallo Femaref,

Ganz klar, es fehlt eine Configuration, die Assemblies werden bei jedem Startup gescannt ...

Falsch. Schau dir mal MEFContrib an.

... Dependency Tree wirklich zu testen.

Schau dir mal MEFX an. MEF stellt - soweit ich weiß - sogar eine Library bereit, um seinen Code analysieren zu lassen.

Ist neben der höheren Startupzeit gewiss ein Nachteil, ich denke aber, dass es sich mit den Vorteilen im Plugin Bereich definitiv lohnt.

Bezweifele ich.

zero_x

Hinweis von herbivore vor 13 Jahren

Zu klären, ob MEF nun ein IoC-Container ist oder nicht, sprengt den Rahmen dieses Threads. Wenn ihr das weiter diskutieren wollen, benutzt bitte den verlinkten Thread.

U
1.578 Beiträge seit 2009
vor 13 Jahren

Ich benutze keine Container, ich benutze nur einen ServiceLocator...

1.820 Beiträge seit 2005
vor 13 Jahren

Hallo!

Ich benutze z.Zt. (noch) einen eigenen DI-Container, mit gelinde gesagt rudimentären Funktionalitäten. Ich würde gerne entweder einen bereits vorhandenen verwenden, scheue mich aber vor der Einarbeitung (jaja, ich weis: Ist ein dummes Verhalten. Ich schieb' auch immer meine Steuererklärung bis zum Maximum raus).
Oder zumindest würde ich mein eigenes so erweitern, dass es später möglichst einfach gegen ein anderes ausgetauscht werden könnte (wofür es ja mittlerweile auch ein Interface bzw. eine Service-CKomponente auf CodePlex gibt, hab' nur den Namen vergessen), ich scheue ich aber wiederum den (evtl. unnötigen) Entwicklungsaufwand.
Vorteil bei meinem eigenen DI-Container sehe ich darin, das ich rel. schnell Anpassungen vornehmen kann, Nachteil ist die Funktionalität und die Kompatibilität.
Vorteil der fertigen DI-Container ist die Funktionalität, Nachteil die Einarbeitung (ok, ein subjektiver Nachteil) und Kompatibilität (wird teilweise relativiert durch o.g. Interface).
Aber bald ist ja Weihnachten, und da hat man ja immer sooooo viel Zeit. 😉

Nobody is perfect. I'm sad, i'm not nobody 🙁

1.378 Beiträge seit 2006
vor 13 Jahren

[LightCore] - weil es sehr einfach in der Handhabung ist.

In der letzten Firma haben wir Unity eingesetzt, was aber wahrscheinlich dank der Komplexität(keine Ahnung) dauernd Probleme gemacht hat.

2.187 Beiträge seit 2005
vor 13 Jahren

Hallo kelkes, Hallo @All,

Castle Windsor.
... Es drängt sich mir die Frage auf, wie man "keinen DI Container" benutzen kann...

David W hat die Antwort auf deine Frage gegeben:

Ich benutze keine Container, ich benutze nur einen ServiceLocator...

Ach ja: Wir verwenden auch kein DependencyInjection, sondern auch ServiceLocator (aka. Microkernel, Factory, AbstractFactory).

Gruß
Juy Juka