DAL Architecture

Posts   
 
    
kievBug
User
Posts: 105
Joined: 09-Jan-2009
# Posted on: 09-Jan-2009 16:44:54   

Hi,

We are going to use LLBLGen to generate DAL for our system. Our system has a lot of modules i.e. each module has its own set of tables and also there are some tables like Employees that are shared among the modules. All tables has prefixes according to the module it belongs.

Example of table names: sysEmployee - means that this table is system i.e. shared between the modules sysFolder - a system folder structure docFolder - a folder structure of the documents in Documents module trnWorkgroup - workgroups in Training module and so on.

Also docFolder contains the field like CreateByID which references sysEmployee table. We need to have this link in the DAL too.

Please note: All modules are developed by one team. All modules are deployed together.

I've several questions:

What is the best way to handle such architecture with LLBLGen? Should we have different LLBLGen projects for each module? Or should we have one project for all modules?

I think about having a different namespaces for different modules and each namespace containing only module specific entities/tables . It'd be great to put them into different assemblies(however it is not neccessary). Example: {RootNamespace}.Dal - contains all entities that are shared among the modules {RootNamespace}.Dal.{ModuleName} - contains entities for the module {ModuleName}

Another question is how to remove the prefixes so that on DAL we have Employee and so on.

Thanks, Anton

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 11-Jan-2009 19:03:03   

kievBug wrote:

I think about having a different namespaces for different modules and each namespace containing only module specific entities/tables . It'd be great to put them into different assemblies(however it is not neccessary). Example: {RootNamespace}.Dal - contains all entities that are shared among the modules {RootNamespace}.Dal.{ModuleName} - contains entities for the module {ModuleName}

This isn't possible at the moment. If you want separation of entities, I'd suggest you create a project per group/module. Note that doing this you loose the ability to explicity relate entities between modules/projects.

kievBug wrote:

Another question is how to remove the prefixes so that on DAL we have Employee and so on.

You have to rename the entities to remove that prefix. One useful thing to automate this is EntityFieldNameStripPattern at Project properties:

**EntityFieldNameStripPattern **The pattern which contains two sections, enclosed in {}, one for the prefixes and one for the suffixes. Add prefixes and suffixes to strip off by separating them by a comma. The first match is stripped. If the entity field's name is equal to a prefix/suffix strip pattern, nothing is stripped off. Stripping is case insensitive. A new project inherits this value from the preferences.

David Elizondo | LLBLGen Support Team
kievBug
User
Posts: 105
Joined: 09-Jan-2009
# Posted on: 13-Jan-2009 14:50:10   

daelmo wrote:

This isn't possible at the moment.

Do you have any plans for this one?

daelmo wrote:

If you want separation of entities, I'd suggest you create a project per group/module. Note that doing this you loose the ability to explicity relate entities between modules/projects.

:-( I do not want to loose references for shared entities. Also there should be a reporting module which should actually be aware of all entities. So the only way is to have one project for all modules, but then there will be some problems with merging two(one that is stable and another one that has new module added) LLBLGen projects because they are binary files :-(. Is it possible to have a project file as a text file? Any plans for it?

Do you have a roadmap, list of features that will be included in the next version?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39749
Joined: 17-Aug-2003
# Posted on: 13-Jan-2009 21:46:27   

kievBug wrote:

daelmo wrote:

This isn't possible at the moment.

Do you have any plans for this one?

V3 will support grouping of entities (1 level), and will allow code to be generated with group names as namespaces

daelmo wrote:

If you want separation of entities, I'd suggest you create a project per group/module. Note that doing this you loose the ability to explicity relate entities between modules/projects.

:-( I do not want to loose references for shared entities. Also there should be a reporting module which should actually be aware of all entities. So the only way is to have one project for all modules, but then there will be some problems with merging two(one that is stable and another one that has new module added) LLBLGen projects because they are binary files :-(. Is it possible to have a project file as a text file? Any plans for it?

Do you have a roadmap, list of features that will be included in the next version?

V3 will have an xml file as project file, so you can easily merge project files together with version control systems and the like or manually. V3 will go beta this summer.

Frans Bouma | Lead developer LLBLGen Pro
Posts: 2
Joined: 05-Aug-2010
# Posted on: 05-Aug-2010 04:19:23   

Otis wrote:

V3 will support grouping of entities (1 level), and will allow code to be generated with group names as namespaces

I'm evaluating v3 and cannot get the generator to use the group name as the entity class namespace. Help! confused

MTrinder
User
Posts: 1461
Joined: 08-Oct-2008
# Posted on: 05-Aug-2010 23:34:35   

What is it using as the entity namespace instead? My understanding was that the group names were only used for project names...

Please open new threads rather than resurrecting old ones - it makes it easier for us to keep track of what we are answering.

Matt

Posts: 2
Joined: 05-Aug-2010
# Posted on: 06-Aug-2010 00:46:53   

MTrinder wrote:

What is it using as the entity namespace instead? My understanding was that the group names were only used for project names...

Please open new threads rather than resurrecting old ones - it makes it easier for us to keep track of what we are answering.

Matt

Sure, but then the relationships between groups will break if you use different projects.