Hi Guys,

Background: LLBLGen v2; 1year + experience using adapter model; LLBLGen is great!

Scenario: We’re busy building a massive modular software framework. Some modules are dependent on others. We build separate DAL/DALSpecific projects per module.

Problem: Want to be able to use one shared/generic DataAccessAdapter for most methods that’s shared by the software framework.

Why? Eg.

Module A is dependant on Module B. So in Module B Method Foo() we have

DAA.StartTransaction(IsolationLevel.ReadCommitted, "Save Project"); DAA.SaveEntity(ModuleAEntity); <--- module A’s entity DAA.SAveEntity(ModuleBEnitty); <--- module B’s entity DAA.Commit();

Questions: Is it ok using any DAA to do it like that? Is there a way to create a generic DataAccessAdapter that could be shared by all the modules?

(I know I have to go ModuleX.DataBaseSpecific to get to the procs and stuff.)

Unfortunately we just don’t have enough time or insight in the product( Only got V2 the other day) to confidently go ahead as is.

Would be great to get some elegant solution to this problem.

Thanks,

It's normal to have one Adapter for all the modules.

But What do you mean with the word 'Generic'?

Since a DataAccessAdapter gets generated per ModuleXDBSpecific project I assumed that there are some subtle differences between them.

Referring back to the example we’re using a ModuleB.DataAccessAdapter instance on an entity from ModuleA. So is it ok to do this? Nothing going to break later on? My lack of insight makes me jumpy and having an expert telling us it’s ok does makes everyone more comfortable.

I assume you are creating one LLBLGen Pro project for each module.

From these you should take the DBGeneric projects.

And then you would create a general LLBLGen Pro project which has all the entities of all the modules. And you should take that General DBSpecific to use it from you application.

So now you should have something like General.DataAccessAdapter rather than ModuleB.DataAccessAdapter or ModuleA.DataAccessAdapter.

The problem is we don’t want to distribute any entity, sp declarations/methods that aren’t being used by the module. Should the client decide to purchase Module W we don’t want anything related to the other modules distributed.

You may package the entire Database Specific DLL to all your installations, and then you may just distribute different Database Generic projects based on the selected modules.

And if you have a Bussiness Layer, you may choose to make this separation at the "BL" level.