1

I am using StructureMap to do DI in my ASP.NET MVC Project. I have divided my libraries into the following 3 dlls.

  1. Core
  2. Services
  3. Data (Contains repositories)

The core simply contain all the interfaces and services and data contain their implementation.

Now when I setup StructureMap in the website I need to tell it to scan the services and data assemblies as they contain the implementation of the core interfaces but this would mean I will have to reference them both in the web project although it depends on service project only which then depends on the data project.

To me referencing these two dlls in web project does not make sense as it spoils the benefit of abstraction?

Can some one please explain to me if I need to reference these assemblies or not and then what is the advantage of using separate interfaces in the first place?

Steven
  • 166,672
  • 24
  • 332
  • 435
Afraz Ali
  • 2,672
  • 2
  • 27
  • 47
  • 1
    possible duplicate of [Ioc/DI - Why do I have to reference all layers/assemblies in entry application?](http://stackoverflow.com/questions/9501604/ioc-di-why-do-i-have-to-reference-all-layers-assemblies-in-entry-application) – Steven Jul 23 '13 at 08:21

1 Answers1

2

The web project is the composition root of your application. The composition root is one single place in the application that composes the object graph for the application. You don't have to reference the assemblies from the composition root, you can scan the assemblies using a convention, but it's often not worth the effort IMO.

By having the composition root reference the dependencies you flatten out the dependency hierarchy allowing looser coupling; see Mark Seeman's excellent explanation here.

Dividing your application into different projects (assemblies) allow you to reuse the functionality in the assemblies between different applications and also to load parts of the application on demand (using a plug in architecture). Don't overdo it. Think of why you split the solution up. Other programmers can violate your intended architecture even though your split the solution into multiple projects to prevent references in the "wrong direction".

You're asking what the point of using separate interfaces is. Interfaces provide one way to make abstractions in your code to allow loose coupling and composability. By programming towards the interface and not the concrete implementation, you can easily change the implementation without changing the depending code. This allow you to change and adapt you application easier.

Community
  • 1
  • 1
PHeiberg
  • 29,411
  • 6
  • 59
  • 81
  • Thanks for your answer. It clears a lot of confusion in my mind but I have ended up with the same question that you have highlighted yourself. Other programmers can violate my intended architecture even though I split the solution into multiple projects to prevent references in the "wrong direction". How do you tackle this problem then? Should I copy all the DLLs to bin folder and use assembly-scanning rather than referencing them? Is that the recommended approach? – Afraz Ali Jul 25 '13 at 08:34
  • No matter how hard you try, other programmers will find ways to corrupt the architecture. I think this is a matter of education and communication, rather than trying to solve it technically. My thought is: go with the simplest approach and spend the time making the architecture evident, rather than to complicate things trying to make it fool proof. – PHeiberg Jul 25 '13 at 08:44
  • I agree with your thought, Marked as answer Thanks! :) – Afraz Ali Jul 25 '13 at 09:31