Reputation: 15761
I am using the EF --> Repositories/UnitOfWork --> Services --> MVC 3 layering approach, and I was just wondering what the benefits/drawbacks are of using separate assemblies or combining some of the logical layers in assemblies.
Basically what I am asking is that if you program to a contract (interfaces) and not an implementation, you could do it in an single assembly correct?
Upvotes: 0
Views: 146
Reputation: 2736
Another advantage of separate assemblies is easier reuse and swapping of components. For instance, if you would like to create a WPF frontend for the same application, you could use the same layers as the MVC3-project, just swapping the Web project for a WPF application. It simply makes sense to separate clearly distinct areas of an application to be able to more easily change them at a later point.
Upvotes: 2
Reputation:
Using multiple assemblies means you can enforce "hidden" and "public" interfaces, by internalising certain interfaces and classes so they can only be used by classes in the same assembly - this means you can have helper and extended classes available for a given layer, and you aren't in danger of just saying "sod it" and using them where you shouldn't.
It's a way of enforcing the tiered nature of your approach that just using namespaces etc cannot do.
Upvotes: 1
Reputation: 171178
Using assemblies you can enforce the layering using just the built-in tools.
You can achieve the same effect with namespaces though. You just need a tool that is able to validate namespace dependencies such as NDepend.
Interfaces have nothing to do with this discussion. They provide compile-time separation. The runtime dependencies are still there. Just not visible statically.
Less assemblies are often preferable from a build-performance perspective. They also sometimes just get in the way ("Cyclic reference detected!").
Upvotes: 5