Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Strengths and weaknesses of dependency injection

456 Aufrufe

Veröffentlicht am

Concepts like the Dependency Inversion Principle, Inversion of Control containers and Dependency Injection libraries are often mixed up, but they are not the same. You shouldn’t use a DI library until you understand the problems your solving, nor is it always the best solution.

Since I’ve felt this pain many times myself, I’d like to use this session to create some clarity. First, I’ll demonstrate the reason why people typically use libraries like Unity and Autofac in their code bases. Then I’ll show you that those same people often use the Dependency Inversion Principle in the wrong way (and need to revert to mocking libraries to compensate). Then I’ll show you how to apply the principles properly by carefully designing the seams in your architecture. And finally, I’ll show you how an advanced library can connect the dots in a very elegant way.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

Strengths and weaknesses of dependency injection

  1. 1. Dennis Doomen | @ddoomen | Aviva Solutions | The Continuous Improver
  2. 2. Order Processing IOrderRepository Nhibernate OrderRepository Storage RavenDB OrderRepository Storage Storage In-memory Repository Bookkeeping Diagnostics Decorator Diagnostics Decorator Strategy Selection Allow Test-time dependencies Inject dependencies from different modules Control lifecycle (e.g. per http request, singleton, etc) Inject Cross-cutting Concerns Promote depending on abstractions
  3. 3. Order Processing IStoreOrders<T> + CreateQuery<T>(); + Add<T>(); + Delete<T>(); NHibernate Repository Order Processing IStoreOrders + GetIncompletedOrders(minValue); + StoreOrder(); + CompleteOrder(); OrderRepository VS
  4. 4. • Don’t use the Service Locator pattern • Use container only at the root… • …so don’t use the container as a dependency • Constructor injection only • Pass local dependencies to methods • Avoid container-specific dependencies • Use delegates for factories, indexes, etc. • Include registrations in at least one test • Use types explicitly in registrations • Let the container handle the life cycle • Access date & time through delegate • Avoid configuration-based setup (e.g. XML).
  5. 5. System Package Package Package PackagePackage Package Maybe Probably not Probably yes TinyIoc Autofac