General class/namspace design

Hi everyone,

I have a question regarding general class/namespace design when working with Lightspeed.

The problem I have:I have put the mapping classes (i.e. the classes inheriting from Ligthspeed’s Entity-Class) into a namespace IO.DatabaseAccess. According to my opinion these classes clearly belong to the IO-Namespace, since these classes are the direct interface to the databases.

However, on the other hands, I use these classes in my business-logic. I have two databases. One to store configuration states and another one to store application related information. For both topics there are two namespaces, i.e. “Settings” and “WebUserHandling”. Beyond those classes for the database access (i.e. the lightspeed-mapping-classes), there are further classes belonging to both namespaces.

So...

• ...either I put the mapping-classes in “IO.DatabaseAccess”. Advantage: Database-related mapping can be found in one folder. Disadvantage: The business-logic-classes belonging to “Settings” and “WebUserHandling” (which are more than the mapping-classes) are dispersed on two folders.
• ..or I put the mapping-classes in “Settings”, respectively “WebUserHandling”. Advantage and disadvantage the other way around.

Is there an alternative approach, something I haven’t considered yet?

Which approach do you recommend?

Thanks for your answer, Henning

My opinion (and others may disagree) is that it depends on how you plan to use the LightSpeed classes.

If your classes are fully-fledged domain entities which your application works with directly as part of the business layer, then you should namespace them accordingly.  I.e. they should be in your main model namespace or some other namespace that describes their function (e.g. Settings or WebUserHandling).

However, if you are using LightSpeed essentially as a data access layer, and wrapping the LightSpeed entities in a business logic layer, than putting the LightSpeed classes into a DatabaseAccess namespace makes sense, because now data access is the function of the LightSpeed classes (the business function is in your wrapper classes).

I recommend the first approach (fully fledged domain entities in domain-meaningful namespaces), and this is what we do in our own LightSpeed-based applications.  But in any case this is more about how you design your application and how you use the LightSpeed entities: the namespace decision follows from that.