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.