Multiple Projects with a single DBSpecific

Posts   
 
    
bemert
User
Posts: 6
Joined: 25-Sep-2008
# Posted on: 20-Jan-2010 22:36:33   

We have a single SQL Server database with aprox. 400 tables. What we would like to do is create a DAL for certain groups of (related) tables, instead of having one large DAL for the entire database.

Since all the generated DALs will be connecting to the same database, is there a way to have only one DBSpecific file that each project could use or does each generated project have to have it own DBSpecific file?

Thanks

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 21-Jan-2010 01:56:19   

Hi Brian,

In theory that should work, you have to: 1. Create a LLBLGen project with all your entities, then generate code. 2. Create per-group LLBLGen projects. 3. In your VSNet solution you just need to reference the DBGeneric (from step 1) and the individual DBSpecific (from step 2)

The caveat is that you can't create relationships between entities from different groups. Your individual groups in DBSpecific don't know about entities in other groups.

Although that can work, you don't gain too much. I don't see how divide your DAL and not your DBGeneric will save you performance (unless you can justify that). Other thing you can do is divide both DBSpecific and DBGeneric code, just do the step 2 from above list.

David Elizondo | LLBLGen Support Team
bemert
User
Posts: 6
Joined: 25-Sep-2008
# Posted on: 21-Jan-2010 18:21:00   

Thanks for the insight.

We are not really looking to gain anything in performance, but rather modularize the DAL, so the components can be used within other applications (i.e.: RSS Feeds and Web Services). The reason behinds this approach, is if we are only working with a certain module for RSS feeds, then why have the entire entity in the DAL, this would only confuse the developer and possibly 3rd party developers as well (Give them only what is needed).

As for entity relationship, that isn't an issue either, since the bulk of each group will actually not need to communication with the other groups. Most of this will be handled on the SQL Server anyway, using Views and SPs when needed.

Thanks