Is it better to have more number of dll's

Question

Hi, I'm designing an application. I found that to make it more modularize, the number of dll's getting increased. Is it a better design to have more number of dll's?

Regards ArunDhaJ

Answer 1

This is a common but tricky question. Personally I don't like overly fragmented dlls, as it makes it quite hard (IMO) to track and deploy. I prefer a limited number of more chunky dlls.

In addition to project/dll management, this also reduces the amount of work "Fusion" has to do when loading things.

You should obviously aim for reusable components, but just don't go mad making them too granular - consider "System.Windows.Forms.dll", for example; quite a lot in there!

Vertically, the obvious ones to keep separate are UI / repository / logic concerns; horizontally I tend to have one column of dlls per logical area - but you can still compartmentalize that with namespaces, so you don't have to keep a dll to just one thing.

Answer 2

The goal is not to have a certain number of assemblies, but to have a meaningful separation. Certain architectural models suggest a certain structure, e.g. a 3-tier application might have separate assemblies for data access, business logic and front-end (and keep in mind that the dependencies between your assemblies ideally form a tree).

Answer 3

I think this question is subjective, because it depends on everyone individual opinion.

In my opinion, a project should need as many dll's as there are modules, not including dll's for data and business tiers.

In general, components of an assembly that belong together should of course remain together. Marc Gravell's example of System.Windows.Forms is a good one IMHO.

Answer 4

That is a very general question... I don't see why not as long as the dlls do not depend on one another.

Answer 5

Each dll loaded adds a little overhead (the OS needs to keep track of it, more dllmain's to call for each thread start/end.

But in practice, unless the number of dlls is enormous (hundreds) these overheads a likely to be not significant.

Many dlls is more to install (and update), and means more projects to build in development.

But the balance of modularisation vs. lower overhead is always going to be highly subjective and only really answerable in the specific.

Answer 6

this depends but i would say yes,

it's easier to use them for future projects and also you can compile the one you are working with which can decrease the compiling time depending on how large your project/other dlls are.

Answer 7

Is it a better design to have more number of dll's? = Is it a better design to have more modules?

So, if that it depends of your application logic, how big is it, how many logical "layers" it uses.

It's up to a application architect(eventually you) to divide this layers.

surely it's better have more little functions that a big one, but this rule isn't true for application modules(solution projects)...

Answer 8

There is no right/wrong answer to your question, its just down to a matter of preference. I would say as a general rule of thumb, try to keep your DLLs to a minimum, reason being it's just easier to manage.

Classes need to merit their own DLL so if you feel you have quite a few classes that relate to specific areas of functionality (such as DAL, BLL) it is common practise to move these into their own assembly.

If you have just a few classes that perhaps relate to a specific area you can just section them off using a separate Namespace (as Mark suggested).