.NET Project Architecture

Question

I have sort of a philosophical question, which also need to consider the performance impact.

We are designing a new system with many sub-services that are not related to each other, yet, some may use each other (We are using unity to avoid any decoupling).

My main question is:

• Should we break them into separate DLL's, where each service has his own dll (like product.services.serice1.dll,product.services.serice2.dll, etc.), or we should consolidate all those services into a single DLL, with difference name spaces, to seperate between them. It term of performance, is there any difference between the two? also, what is the most "Acceptable" standard that being endorsed by the community (and Microsoft)?

Thanks

Answer 1

If your services are meant to be used together, group them in the same assembly. I've seen systems with zillions dll loaded (and solutions with zillions projects in it) with not a single instance where it was needed to cherry pick one assembly over any other. That does not preclude you from having decoupling and sane separations in namespaces.

As far as performance go, there's no real impact wrt number of dll's loaded (if you stay sane and don't go for thousands of them), but the impact is HUGE in developement if you stick with the default behavior of VS who loves to copy every reference in every project's bin/debug directory. On middle to big solutions (1000's of classes) the build process will be a lot longer and more frustrating.

Think of an assembly as a unit of deployment. If stuff is meant to be deployed together, stuff your stuff in the same assembly.

As a warning on how frustrating a project split in too many assemblies can be, look at the NUnit distribution. Over 30 different dll's, some you have to reference to be able to have unit tests, some you don't and you end up hunting for the types you need.

Answer 2

Deployment is a big issue here. If all of this functionality is going to be deployed on a single machine I would suggest a single .dll, with different namespaces for behavioral separation. A single .dll will avoid many future issues with inter-.dll compatibility and greatly simplify deployment and installation.

Paul