.NET Project Architecture

Question

Hi, 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

Personally, I'd separate them into independent DLL projects to simplify development, testing, & maintenance.

Answer 2

I strongly prefer breaking them into separate projects and assemblies, when they are separate "services".

If you put everything into a single assembly, any client that wants to use any service will automatically load the entire assembly. By breaking them up, you can keep the memory usage down between separate client applications, and only load things as needed. Technically, loading one assembly is faster than loading many assemblies, but it is not faster if you're lazy loading assemblies in terms of perceived performance.

Once the assemblies are loaded, the performance should be identical.

Answer 3

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

Answer 4

Don't optimse prematurely. I'd seperate the namespaces until you have a requirement to join them as a local optimisation.

Answer 5

I like to develope a large system as several separate assemblies/DLLs, to promote there being an architecture. After that you can, if necessary/desirable, repackage the functionality into a single assembly before deploying it.

Answer 6

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 7

.NET assemblies represent a physical artifact to package stuff you should never be used to architecture thing. In other words, use as few assemblies as possible, and preferably use only one .NET assembly. All details here:

Advices on partitioning code through .NET assemblies