few big or many small dlls [closed]

Closed. This question is opinion-based. It is not currently accepting answers. 开发者_如何学Go

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this 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 ?

---

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.

---

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.

---

Our company originally took the approach of making many DLLs. We have found that it creates significant maintenance problems. Now we are moving toward fewer DLLs. This means that when different products use our common components they often have more classes than they possibly need, but that is not a terrible problem.

---

There is no real concrete answer here. In general, it's good to lean toward more smaller / loosely coupled modules, than fewer tightly coupled monolithic modules. Personally, I wouldn't worry about the runtime overhead as it's not really significant when compared to the design / architecture of your application.