Class bucketing . . .

Question

Ok, so i have been trying to put everyone one of my classes in some root folder, either:

UI
BusinessLogic
DataAccess
BusinessObjects
Interfaces

i have a few more where i can't seem to bucket very well so i am looking for suggestions

1. A Cache class that maintains a private dictionary and allows different access to objects based on some specific keys

2. Event Arg classes?

Also, under a project i now start to have sub systems that have all 3 (data access, business objects, busiensslogic). How should i break up the folders structure?

A.

ProjectX
--Subsystem1
----BusinessObjects
----DataAccess
----BusinessObjects
--Subsystem2
----BusinessObjects
----DataAccess
----BusinessObjects

or

ProjectX
--BusienssLogic
----Subsystem1BL
----Subsystem2BL
--DataAccess
----Subsystem1DA
----Subsystem2DA
--BusinessObjects
----Subsystem1BO
----Subsystem2BO

or

ProjectX
--BusinessLogic
--DataAccess
--BusinessObjects
(with no subdirectories for each functional subsystem)

Answer 1

I usually like to stick to the 1 class, 1 file rule, but when it comes to EventArgs, I actually like to declare them in the same file that I define the delegate or event. Unless, the args are used by more than one class hierarchy, which doesn't tend to happen to me often.

As for the cache, I would put in the folder of the classes in which it supports.

As much as I like good organization, one can get too anal with it.

Answer 2

There is no one right way to do this.

Download few open source projects using similar technologies to your project and take your ideas from them.

Sorry, I missed the C# tag. Examples of good .NET projects have been covered before here and here.

Answer 3

This is mostly personal taste.

I agree with what Brian Genisio said concerning where to put EventArg classes etc.: if you only use them once, put them in the same file where you use them. For general classes/files, I always have a 'General' folder (how convenient! ;-))

Concerning the folder structure: I'd go with the second one, that one is 3 tier AND keeps the subsystems separated. Win-Win!

Answer 4

I just want to add a comment on names. I feel the word business leads to misuse. We did this, and now we don't know what's it about: domain logic or service layer. I would suggest names like Domain. Domain.Impl (to separate interfaces from Impl) and then Services...and maybe Persistence if you are using ORM...it may be different if your using different approach, but to be honest, I am confused about names BusinessLogic, DataAccess, and BusinessObjects. I don't understand what is what. BusinessObjects should contain business logic, logical? Or are they just DTOs? Then why are they in a separate project from DataAccess?

Answer 5

I try to align my assembly names with their namespaces, and use the .NET Framework itself as a guideline. I firmly believe that working with a namespace structure that drives a folder structure makes for a much more maintainable codebase.

For example, I have a caching provider that is part of the global developer framework that we use. It lives in a namespace of something similar to:

[Company].Core.Data.Caching

I have other data related functionality that also logically falls underneath the Data feature, so caching has siblings like Adapters, Converters, and Generators. So, let's assume we have the following namespaces:

[Company].Core.Data.Adapters
[Company].Core.Data.Converters
[Company].Core.Data.Caching
[Company].Core.Data.Generators

These related namespaces live in an assembly called [Company].Core.Data, which is also the project name. Finding things in the solution becomes very simple following this structure. Speaking of structure, now we get back to how they are stored on disk.

The project name is the root folder name. This assumes my source control folder, which is "C:\Source Control" on my local machine:

C:\Source Control\Core[Company].Core.Data\
C:\Source Control\Core[Company].Core.Data\Adapters
C:\Source Control\Core[Company].Core.Data\Caching
C:\Source Control\Core[Company].Core.Data\Converters
C:\Source Control\Core[Company].Core.Data\Generators

So, as a hierarchy, it looks something like:

[Solution]
--[Company].Core.Data
----[Adapters]
------(Adapters files)
----[Caching]
------(Caching files)
----[Converters]
------(Converters files)

I put all projects at the same level, and vary sub-namespaces with folders. This way the namespaces and the physical structures are easy to reconcile. The hard part is finding balance. You don't want to have a large number of smaller assemblies, so I normally will group them at a higher level, and eventually refactor it when either it is trending to grow too large, or if sub-namespaces change more frequently than other parts.

I have been doing this for years now, and it is very comfortable for not only myself, but for my developers to use.

As for your EventArgs question, I agree with the consensus that I normally do one class per file, but will make the exception to place an EventArgs class with another class if it is singular usage. For multiuse, I put them at the highest logical point in the assembly, allowing the namespace structure to bind my scoping.