Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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?
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!”).