Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Are there any guidelines for deciding when a class should be in its own assembly/DLL? I often see two schools of thought:

1) Every "grouping" of classes belongs in its own DLL e.g. Repositories, Services, DTOs, Infrastructure, etc.

2) Everything should be in a single DLL but separated out via namespaces/folders e.g. have a "Core" DLL with additional namespaces e.g. Core.Repositories, Core.Services, Core.DTO, etc.

At work we just lump everything in a single Assembly called "Business". There are some folders but there's no real separation - business objects (with logic, some of which shouldn't even be classes) are lumped in a "BusinessObjects" folder without care. Things used in more than one class are in a "Core" folder. Utilities are in a "Utilities" folder, the data access infrastructure is a "Data" folder - you get the idea.

For a new module I'm working on I want/need to have a separate data access layer (think a rudimentary Repository implementation) but I don't want to just throw it under the "BusinessObjects" folder with the other 160 (!) classes there. At the same time I'm concerned about creating a new Class Library since everyone is used to stuffing a class in the single Library; a folder/namespace could work however.

share|improve this question

3 Answers 3

up vote 5 down vote accepted

I find it's better to have more projects (i.e. assemblies) with classes divided by category in each project than one project with all of these classes in separate namespaces. You should aim for your projects to be reusable and to represent different layers in an application. You can then feasibly reuse these projects in future applications without having to include a whole bunch of unnecessary classes.

For instance, based on what you have mentioned, I would definitely have the following projects:

  • Core
  • Data
  • Domain (or BusinessObjects)
  • Services
  • Utilities (or Helpers)
share|improve this answer

Some other guiding princicples I work with:

  • Do you think you will re-use this code in other projectS? For one group of related web applications, we had one user account-related module that all the applications made use of, since they all used the same model for user accounts and logins. I've done similar things with geometry and math libraries and reused them in multiple applications, just by including the DLL.

  • Do you want to be able to modify / deploy this code without redeploying / recompiling the whole project? Sometimes it's been useful to just rebuild the module, deploy and restart the web application.

It sounds like in your case a basic and generic Repository could be useful again in the future, it might be worth it to separate it into a new DLL if you can.

share|improve this answer

"Uncle Bob" Martin of Clean Code, SOLID Principles fame has outlined three principles here:

  • The Release Reuse Equivalency Principle: The granule of reuse is the granule of release.
  • The Common Closure Principle: Classes that change together are packaged together.
  • The Common Reuse Principle: Classes that are used together are packaged together.

The general rule of thumb is that you should keep the number of projects in your solution as low as possible. Only split them up if you need to do so in order to implement one or more specific user stories, or if having a single assembly is causing measurable performance issues (typically once they get up to several megabytes in size).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.