I am trying to figure our what is the appropriate granularity for code libraries. Specifically, I want to work out if all my general code libraries should be rolled into a single DLL, or if they are better separated into separate DLLs, one for each discrete area of functionality.
I have a a set of code libraries that are shared across applications. They include code to manage database access, read configuration from our centralized configuration repository, perform standard transformations on data from external sources, and a whole lot of other things besides. Some of these libraries have dependencies on others (e.g. database access depends on configuration repository code). Others are fairly independent. Some applications need all the code, but most just use a sub-set (where the sub-set differs between applications).
If it matters, I'm a C# developer, working on enterprise scale applications.
To help me figure out what I should do, I started to make a list of the advantages and disadvantages of each approach. Unfortunately, this has yet to reveal a clear winner:
Advantages of One Big Library
- Only need to add a single reference to client applications.
- Only need to update one DLL when bugs need to be fixed or functionality extended.
- There are less files to deploy, so hosting servers end up looking 'neater'. ie. they typically end up with an executable and a "sharedlibrary.dll" file in them.
Advantages of Multiple Small Libraries
- Applications don't need to drag around dependencies on functionality that they don't need.
- Dependencies are explicit, so it is easy to see what depends on what.
- The DLL names indicate the kind of code they contain.
What other factors should I consider? Have I missed any significant advantages / disadvantages of either approach?