Several large or many small dlls

Question

We have a discussion at work on how to develop our application.

Make a few relatively large ones or use many dedicated libraries.

Several times we use our dlls in our different products.

What is the usual practice with it in a .net environment.

Is the boot time really different?

Answer 1

I never bought the "many links = bad" idea, which many .NET developers think so. I honestly believe that the best separation is good, especially when you get the opportunity to reuse your code for other projects.

If you look at the Rails or Django communities, it was very encouraging and even somewhat expected that you would split your application into small reusable parts. There really are no drawbacks, but there are many advantages. Often your code is cleaner because you have to think about things in logical units.

In the .NET community, I saw a lot of people just wanting to squeeze everything into one monolithic DLL, and in my opinion this is wrong. Why are links to projects bad? Why is it bad if you have micro-libraries, each of which performs its own unique task? The answer is that this is not bad. We must decide on separation of concerns and dry principles.

Answer 2

Is the boot time really different?

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

Personally, I would design a usage-based class library structure.

There are two competing goals, and the right balance depends on how you use the libraries.

• Fewer partitions (fewer libraries) typically result in easier development and easier maintenance.
• More separation (more DLLs) leads to more flexibility and potentially less deployment, as different products can choose and choose what they want.

I prefer to have as few libraries as possible if each library functionality is unique. If a large dependency is required, I will try to keep this isolated in the library to avoid having to deploy this dependency.

Answer 3

Our company initially took the approach to creating multiple DLLs. We found that this created significant maintenance problems. Now we are moving towards fewer DLLs. This means that when different products use our common components, they often have more classes than they may need, but this is not a terrible problem.

Answer 4

There is no real concrete answer. In general, it is good to lean toward smaller / loosely coupled modules than towards less rigidly coupled monolithic modules. Personally, I would not worry about exceeding the runtime, since this is not very important compared to the design / architecture of your application.