We have an application built around LLBLGen for which we are creating a plugin system. Each plugin comes with an LLBLGen DAL of its own. How can this DAL be integrated into the DAL of the main application?

Basically, the following scenario needs to be possible: the DAL of the plugin has a typed list X, which it asks the main application to show inside a gridview. The main application however, only has DataAccessAdapters of its own DAL. So how can the DataAccessAdapter of the main DAL be used to show a typed list of the plugin DAL? (Note that I do have control over the point where the DataAccessAdapter of the main application is created.)

Is there any other way that the sharing of Entities could be accomplished? One might generate Entity and TypedList Types dynamically at runtime, using Reflection.Emit. But the problem of "adding" them to the DAL of the main application remains.

Thanks!

IMHO, you don't need to add them to the app DAL, or merge them with it.

As you are using Adapter template set, you have two dlls per plugin, so you have for three plugins: XModel, XAdpater, YModel, YAdapter, ZModel, ZAdapter assemblies. In your main application you could have an 'Active' IDataAccessAdapter variable that you can set depending on the sub-app (or plugin) that you are running.

It's also a matter of who has the control on your application and how you want to share objects and control from your main app to the plugin. For instance, the plugin could simply have a IPlugin.Execute() method. Or maybe you want to expose the IPlugin.IDataAccessAdapter of the plugin to use it in many ways. So, it's more an architectural decision of yours.

There are things that I don't have control over, such as the code which shows a typed list inside a gridview. It requests DataAccessAdapters asynchronously (when the user scrolls, for instance). So there is no way that a central "active" DataAccessAdapter would work.

This is why I do need some way to accomplish my initial goal.

As to the architecture: except for the typed list part, it really is IPlugin.DoSomething(). However, I don't want to rewrite all the code to show TypedLists inside grids.

Each adapter implements IDataAccessAdapter. Each typedlist also implements a generic interface, ITypedListLgp2. With those you can create generic code which can work with instances from any of your plugin's code.

I don't see what the central DAL has to do with anything, if the typedlist is to be filled with the dal related to the selected plugin. Or what you mean with 'DAL', is that the dbspecific project?

IMHO, if you want this to work, you should ask the plugin to create an object which contains an instance of the plugin's DataAccessAdapter and an instance of X. The object then provides X to the grid to bind to and provides the adapter to fetch X. The code using this object works with IDataAccessAdapter and ITypedListLgp2 so it's not bound to anything specific.

BUt without more information I can't help you further: there are too much unknowns, e.g. why you can't change the code which is actually the problem here, why the plugins have their own 'dal's but data-access has to use the application's dals.

We do support a single dbgeneric project with multiple dbspecific projects, if the mappings are done in 1 llblgen pro project and to different databases, e.g. sqlserver and oracle: it will then generate 1 dbgeneric project and multiple dbspecific projects (1 per db) so you can fetch an entity X using both dbgeneric projects.

However this is the opposite from your situation it seems: you have multiple times a dbgeneric project, and you want to fetch a type from that using multiple dbspecific projects (the plugin one, the ones in the main application).

Thanks for the comprehensive answer.

DAL = generic + specific project. My idea was for each plugin to have its own LLBLGen project (that is, both the generic and specific part).

My question is whether it is possible (and if yes, how it could be accomplished) to use the central DataAccessAdapter to fetch a typed list which is part of a plugin's DAL. I cannot simply pass my plugin's DataAccessAdapter to the part of code that fetches the typed list, because of the way a third party DLL is architected.

I wouldn't be asking this question if it were as simple as the solution you suggest.

Clarifications: - The code fetching the typed list is in a third party DLL which cannot be readily changed. - The plugins have their own DALs, and use their own DataAccessAdapters for everything they do (as you would expect). Except for the part where a typed list is fetched.

If you were going to design the system, I'd have recommended either letting each plugin fetch it's own data, or use SelfServicing, that way each object will know how to fetch itself.

But in your case I can't think of a valid workaround.

Fair enough; thanks!