Hello!

I was wondering if (and possibly how) it is possible to use one instance of DataAccessAdapter for multiple projects?

As far as I understand the generated code, the controlling mechanism is the persistence info. If I were able to supply correct info to the adapter, would it be possible to make it work?

I am currently working on a processing framework which will be later used by others to create a client-specific processing implementation. The idea is to have common processing and management classes in the base library and allow other developers to extend data structures to their specific needs.

For example we will handle Client BO as a simple information container with only DisplayName while the specific implementation will be working also with some financial data. For this we will have a Client table and the instance will have a ClientFinancialData table.

I think I could create our Client entity, call overridden method to get the "extending" entity and then project result of a stored procedure onto these entities.

The real question is: can I update these entities in the database assuming they are both in the same database?

And what if a add fields from different projects into ResultsetFields in order to retrieve the data from database?

I went through older posts and found some helpful information but the scenarios were different. Basically - I will be content if someone says that it has a chance to work so I can make some time to investigate further

Thanks for any help and suggestions.

Jakub

Hi Jakub, Dont exactly an answer but share a similar experience:

Our Project Team are working in a Accounting Project. The application have many modules (subprojects). There are sub-teams working on each subproject.

The project has 3-tier: DAL - BL - GUI. LLBLGenPro Adapter TemplateSet generates DBSpecific (DAL) and DBGeneric (this we use as a shared ClassStructure project among others modules).

So, each subproject has its own BL. Each BL manages the rules and delivery information. For instance BL decides what to return, what to ask, what to prefetch, what to sort.

What if the BankManager module wants to register the info in accounting system? Well BankManager project reference AccountingManager module and use its methods. What if the GUI wants to validate the user before start to do transactions? Well it references the AdminManager module and use the Login method.

The AdminProject has nothing to do with AccountEntity and can see it. However can't do anything but see it.

This is possible thanks to that all modules are using the shared ClassStructure project (DBGeneric) and all of them reference the DAL class.

Sketching the project, we had 3 options: A. Do a gigaProject with all the DAL - BL - GUI. B. Do separates projects at all tiers: different LGP, different DAL, different BL, so on. C. Share the DAL and DBGeneric and do separates BL and GUI projects.

We chose "C" coz for us was the most flexible and less-cost option. Flexible: we can do a new project and use all the Class framework existing and others existing BL projects.

Hi David,

thanks for your input. The idea sounds really interesting and we may use something like that for a different project but unfortunately this is not the case. (Btw: do you build separate DBGeneric project with shared entities or do all the DBSpecific projects use one common DBGeneric?)

As I said before - I am creating a processing framework on top of which actual implementations will be prepared. But the "custom" data structures will not be a separate modules - they will be built on top of our base ones.

The idea is to have a complete set of basic data and processing functionality which could be extended by adding custom tables and by plugging-in an instance specific commands. The instance developer should be able to create a new solution simply by adding a table for their specific needs, hopefully assign custom DBGeneric entity to the core one (Client - ClientFinancialData) and create custom commands/actions specific for their needs. Afterwards the instance should be fully functional and executable.

The "command" will be probably an interface implementation:

public interface ICommand 
{
  void Execute (Client clientContext);
}

while Client is a core business object containing also custom information:

public class Client
{
   public string DisplayName{get;set;}
   public IEntityFields2 AdditionalInfo {get;} //maybe IEntity2 property
}

The custom command will know what kind of additional information to expect and will work mostly with this information since we will provide the "common" commands with the core.

Actually, this is a second version of our system and since I can break all backward compatibility I am trying to learn from our past experiences and:

• allow the instance specific database structures while
• still maintain the common core libraries and structures (mainly to simplify new implementations and following maintenance)
• maintain at least some kind of database system independence
• minimize the database roundtrips - the number of "clients" processed should be greater by orders of magnitude and while we can add more application servers, the MSSQL database cluster cannot be scaled as easily. One fetch / one save seems like a really neat idea in this scenario.

I am sorry if the description is vague, but the solution is quite complex and I hope that its detailed description is not necessary to get my idea across.

Thanks again.

Jakub

(Btw: do you build separate DBGeneric project with shared entities or do all the DBSpecific projects use one common DBGeneric?)

What I understand is that he uses a common DBGeneric.

The idea is to have a complete set of basic data and processing functionality which could be extended by adding custom tables and by plugging-in an instance specific commands. The instance developer should be able to create a new solution simply by adding a table for their specific needs, hopefully assign custom DBGeneric entity to the core one (Client - ClientFinancialData) and create custom commands/actions specific for their needs. Afterwards the instance should be fully functional and executable.

I think the easiest/best solution is: The same way an instance developer opens the SQL Enterprise Managger (for example) to define new tables in the Base Schema, and maybe add some fields to an existing tables. He should also open the LLBLGen Pro project in the Designer (better to use a copy of the Original Base project), Re-Scan the database catalog and re-generate the code. This will incorporate all the changes needed into the generated code.

You will always have an untouched Original/Basic version of the LLBLGen Pro project to act as a starting point for new implementations.