C# Architecture – When to Place a Class or Module in a Separate Assembly/DLL

Architecturecdirectory-structure

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.

Best Answer

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)
Related Topic