依赖注入实现

Question

I have three layers in my solution, Presentation (winforms project), Domain (class lib) and Persistence (class lib). I am trying to implement dependency injection to decouple them. My application root is in my presentation layer. I understand the only time the DI container (unity in this case) should be referenced is in my application root, otherwise I would be simply replacing class dependencies all over the place with a dependency on my DI container (which I suppose is still slightly better).

So with these foundation concepts in mind, I am really struggling with the specific implementation. Perhaps my application root should be in its own seperate project - perhaps a console application. I can then resolve the first 'overallApplication' class, listing IPresentation, IDomain and IPersistence in its constructors. I understand (assuming actual implementations have been registered) the unity framework would then recursively solve all respective sub-dependencies.

In your experience - would you be able to advise if this was a sound approach. I really understand the concept and importance of decoupling, and how this is solved by DI conceptually at a high level, but I am struggling to tie it all together in a real application solution with multiple layers (organised in VS as seperate projects).

Any help or pointers towards examples of proper implementations would be greatly appreciated.

Answer 1

Some thoughts for you in hope that they help.

Throughout your question you make statements such as:

"I really understand the concept and importance of decoupling, and how this is solved by DI..."

The first thing I would evaluate is the understanding that DI != IoC Container (eg Unity).

An IoC container is used to remove boilerplate code that results from an existing DI structure. As such I would suggest you refactor without Unity /first/. Then go back and add Unity to reduce your code.

So that:
-1. Make application Di via manual Ctor, Property, Method, Service Locator injection methods.
-2. After this is setup you should see things like:

public View() {
  var controller = new Controller(new IView(), new model(), new IService(new Dal(ISession(connectionString))), new , new ILogger(), etc.){}
}

-3. Then once you have something like this in your code you can then use Unity to inject all that fun:

public View() {}
Controller Controller {get;set;}  //<- Unity auto builds & populates this for you with all the "new" items normally found in your constructor (or wherever).

While not a production example, it should give an idea of some steps to refactor. Going straight to Unity will put the cart before the horse, so to speak.