few big or many small dlls [closed]

Question

We are having discussion at work how to design our application .

Make few relatively big or use a lot dedicated dlls .

Some times we use our dlls in our different products .

What is common practice with it under .net environment.

Does Load time really so different here ?

Answer 1

I've never really bought into the "lots of references = bad" idea that so many .NET developers seem to hold true. I honestly think that better separation is a good thing, especially when you gain the benefit of reusing your code for other projects.

If you look at the Rails or Django communities, it's very much encouraged and even somewhat expected that you divide your application into small reusable parts. There really aren't any downsides, but there are a lot of benefits. Often your code is cleaner because you have to think of things in logical units.

In the .NET community, I've seen a lot of folks just wanting to cram everything into one monolithic DLL, and in my opinion that's wrong. Why are project references bad? Why is it bad to have micro-libraries that each handle their own unique task? The answer is that it's not bad at all. We should embrace separation of concerns and DRY principles.

Answer 2

Does Load time really so different here ?

This should really not be a deciding factor. Instead, focus on how your products will use the functionality in your DLLs, as well as the logical separation within the different libraries.

Personally, I would design your class library structure based on usage.

There are two competing goals, and the proper balance is dependent on how you will be using the libraries.

• Less separation (fewer libraries) usually leads to easier development and easier maintenance.
• More separation (more dlls) leads to more flexibility, and potentially smaller deployments as different products can pick and choose what they want.

I tend to favor having as few of libraries as possible, provided each library's "functionality" is generally unique. If a large dependency is required, I will try to keep that isolated into a library to avoid having to deploy that dependency.