2

Just recently started to grasp on MVC and design patterns. (back to school at 34 ;) )

I was asked by my teacher to design a two part application. It's a recipe website that as an admin WinForms app.

I started to develop my core domain and then moved on to persistence and then moved to the MVC web app... and then I started reading about Dependency Injection. So I did some digging around and decided to go with Autofac just to apply DIP between core and persistence.

And then I read about Composition Root and it states that the IoC container should remain the closest to the start of your application. Fair enough, but my problem lies on:

a) When I move to my WinForms app won't I need to redo the IoC container for it?

b) Wouldn't it be better to have some intermediate layer that took care of DI between all layers?

Improve this question
5
  • 1
    Open arrow heads usually denote a generalization / specialization relationship. Open circles usually denote an interface but usually have a semi circle as well so it's clear which class is implementing and which class is using the interface. If you're going to insist on using this diagram as-is please make the meaning of the symbols clear. This doesn't look like standard UML to me.
    – candied_orange
    Mar 5, 2017 at 7:15
  • The Uml in itself was not important. I removed to avoid more confusion.
    – João Sequeira
    Mar 5, 2017 at 10:07
  • I don't know much about Autofac, but Niject solves this problem by allowing you to create "modules" of bindings that can be referenced as a library.
    – RubberDuck
    Mar 5, 2017 at 11:21
  • 1
    You need to read this book. It will change your life as a software developer: amazon.com/Dependency-Injection-NET-Mark-Seemann/dp/1935182501
    – Eternal21
    Mar 7, 2017 at 20:32
  • @Eterner21 I'll have a look at it. Thanks
    – João Sequeira
    Mar 9, 2017 at 13:00

1 Answer 1

Reset to default
2

So from my personal experience I've found DI to be a very specific case for each type of app you're developing. We've gone with the approach to define stuff like a per web request life cycle for some dependencies, but once you move to building some background job processor then there's suddenly no HttpContext to tie some of the dependencies to. So because of that we've opted to ensure that we have some tests to ensure that we've correctly setup the IoC container (we opted to use CastleWindsor) so that if the different applications do re-use service layer elements we'll quickly be able to pick up why it had happened. We tend to sometimes get lost in writing re-usable code ONLY and forget that sometimes the context of a problem requires a separate approach in order to allow for easy changes when the requirements of the specific context changes.

So in short my answers to your questions:

a) Yes you'll have to redo your IoC container setup, but this will likely be the case as the lifecycles of your dependencies will be intrinsically different. b) Moving it to some layer might enable re-use, but the day that each context requires a different approach it will likely make the layer redundant and you'll find it easier to just live with managing this.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.