Bucketing class.,
Ok, so I tried to put everyone in one of my classes in the root folder:
UI
BusinessLogic
DataAccess
BusinessObjects
Interfaces
I have a few more where I can't seem very good, so I'm looking for suggestions
-
Cache class that maintains a private dictionary and allows different access to objects based on specific keys
-
Event Arg classes?
Also, within a project, I am now starting to have subsystems that all 3 have (data access, business objects, busiensslogic). How do I split my folder structure?
and.
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
(no subdirectories for each functional subsystem)
source to share
I am trying to align my assembly names with their namespaces and use the .NET Framework itself as a guide. I strongly believe that working with a namespace structure that manages the folder structure makes for a much more user-friendly code base.
For example, I have a caching provider that is part of the global development environment we are using. It lives in a namespace something like:
[Company] .Core.Data.Caching
I have other data-related functions that logically fall under the Data function as well, so caching has siblings like adapters, converters, and generators. So, let's say we have the following namespaces:
[Company] .Core.Data.Adapters
[Company] .Core.Data.Converters
[Company] .Core.Data.Caching
[Company] .Core.Data.Generators
These associated namespaces are in an assembly called [Company] .Core.Data, which is also the name of the project. Finding things in a solution becomes very easy after this structure. Speaking of structure, we'll go back to how they are stored on disk.
The project name is the name of the root folder. 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 this:
[Solution]
- [Company] .Core.Data
---- [Adapters]
------ (adapter files)
---- [Caching]
------ (File caching)
---- [ Converters]
------ (converter files)
I put all projects on the same level and change the submenu with folders. Thus, namespaces and physical structures are easy to match. The hard part is finding balance. You don't want to have a large number of small assemblies, so I usually group them at a higher level and eventually reorganize it when either it gets too big or if the sub-namespaces change more often than other parts.
I've been doing this for many years now, and it's very convenient not only for me, but also for my developers.
Regarding your EventArgs question, I agree with the consensus that I usually make one class per file, but will make an exception to host the EventArgs class with a different class if it is exclusive use. For multiuse, I place them at the highest logical assembly point, allowing the namespace structure to bind my scope.
source to share
I usually like to stick to the 1 class rule, 1, but when it comes to EventArgs, I really want to declare them in the same file as I am defining the delegate or event. Unless, 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 it in the folder of the classes it supports.
As much as I like good organization, you can be too anal with it.
source to share
It's mostly personal taste.
I agree with what Brian Genicio said regarding where to put the EventArg classes, etc .: if you only use them once, put them in the same file where you use them.For generic classes / files, I always have there is a folder "General" (how convenient!; -))
As for the folder structure: I would go with the second, then one of the three levels AND kept the subsystems. Win-Win!
source to share
I just want to add a comment to the names. I believe that business to business leads to misuse. We did it, and now we don't know what that means: domain logic or service level. I would suggest names like Domain. Domain.Impl (to separate interfaces from Impl) and then Services ... and maybe Persistence if you are using an ORM ... it might be different if you are using a different approach, but to be honest, I am confused by the names of BusinessLogic , DataAccess and BusinessObjects. I do not understand what's what. BusinessObjects must contain business logic logic? Or are they just DTOs? Then why are they in a separate project from DataAccess?
source to share