I posted this under Architecture but I haven't gotten any response. I am hoping someone responds in this group.

I have a requirement and I am wondering what the best way to do this is. I understand how the whole plug-in architecture works and I have implemented something like this before. What I am wondering is if anyone has done something like this using LLBL. Here is an example of what I need. This is a simple example, and not really intended to say that this example should be done this way. This is more of a question of whether this is possible or not and how to go about doing it.

Lets say it is a simple ordering web application. What needs to have the plugin ability is the types of things that can be ordered. In other words, one application may need to be clothing and another would need to be electronic. There would be a base class called "OrderableItem" that all of these would inherit from. So you would have "ClothingOrderableItem" and "ElectronicOrderableItem". Every customer would have the core application installed which would contain the "OrderableItem" class. Different customers would get different plug-ins installed that would have the inherited classes. These plug-ins would also create the necessary tables and such when they are installed into the application. My question is how to go about using LLBL to do something like this.

Can I seperate my database tables into seperate projects in LLBL and have a class in one LLBL project inherit from a class in a different LLBL project? Would the LLBL work correctly when the plugin is installed. When someone is searching for items to order, can I tell it to bring back all "OrderableItem" instances and when the plugin is installed it will know to include it in the search? I hope I have explained it well enough to understand.

Thanks in advance.

Syc0F3ar wrote:

I posted this under Architecture but I haven't gotten any response. I am hoping someone responds in this group.

I have a requirement and I am wondering what the best way to do this is. I understand how the whole plug-in architecture works and I have implemented something like this before. What I am wondering is if anyone has done something like this using LLBL. Here is an example of what I need. This is a simple example, and not really intended to say that this example should be done this way. This is more of a question of whether this is possible or not and how to go about doing it.

Lets say it is a simple ordering web application. What needs to have the plugin ability is the types of things that can be ordered. In other words, one application may need to be clothing and another would need to be electronic. There would be a base class called "OrderableItem" that all of these would inherit from. So you would have "ClothingOrderableItem" and "ElectronicOrderableItem". Every customer would have the core application installed which would contain the "OrderableItem" class. Different customers would get different plug-ins installed that would have the inherited classes. These plug-ins would also create the necessary tables and such when they are installed into the application. My question is how to go about using LLBL to do something like this.

Can I seperate my database tables into seperate projects in LLBL and have a class in one LLBL project inherit from a class in a different LLBL project? Would the LLBL work correctly when the plugin is installed. When someone is searching for items to order, can I tell it to bring back all "OrderableItem" instances and when the plugin is installed it will know to include it in the search? I hope I have explained it well enough to understand.

Thanks in advance.

Hi, there. Well, off the cuff you don't really want to use inheritance for what (it sounds like) is primarily a difference in attribute value. If the "ClothingOrderableItem" and the "ElectronicOrderableItem" actually have different attributes (not just different values in the same attributes) then it makes sense to use inheritance.

A plugin architecture is, by definition, a dynamic system. So, your plugins will have to understand the additional attributes innately, while hooking to a system that works dynamically.

In LLBLGen Pro, there is a Fields object which allows for late bound access to fields. I believe there are also GetDependantEntities() and GetDependingEntities() methods as well that may be useful for late bound access.

You will not be able to get strongly-typed, early bound access to LLBLGen entities however, as, since the data access and domain infrastructure is generated as a unit per schema, you can't actually generate the entities without them being a part of the final schema.

Now, with your plugin idea you can go through a registration process wherein the appropriate DDL is executed against the database, the project file is loaded, then refreshed with the schema changes, the code regenerated, then dynamically compiled and linked back into the main system. However, once the DAL assemblies (DatabaseGeneric and DatabaseSpecific) are loaded, I believe they are locked until the process shuts down. You'd have to have some sort of external bootstrapper kick in, ask the main process to shut down gracefully while the regeneration process is kicked off and then reload the main process which would then reload the newly compiled DAL.

A lot of work.

I'm not sure the plugin idea is the best direction given the amount of work required, the limitations of the systems involved, and the potential return, but I don't know anything about your requirements. However, if you want to implement a dynamic attribute system, there are other ways of doing it...

Jeff...

jeffreygg wrote:

Syc0F3ar wrote:

I posted this under Architecture but I haven't gotten any response. I am hoping someone responds in this group.

I have a requirement and I am wondering what the best way to do this is. I understand how the whole plug-in architecture works and I have implemented something like this before. What I am wondering is if anyone has done something like this using LLBL. Here is an example of what I need. This is a simple example, and not really intended to say that this example should be done this way. This is more of a question of whether this is possible or not and how to go about doing it.

Lets say it is a simple ordering web application. What needs to have the plugin ability is the types of things that can be ordered. In other words, one application may need to be clothing and another would need to be electronic. There would be a base class called "OrderableItem" that all of these would inherit from. So you would have "ClothingOrderableItem" and "ElectronicOrderableItem". Every customer would have the core application installed which would contain the "OrderableItem" class. Different customers would get different plug-ins installed that would have the inherited classes. These plug-ins would also create the necessary tables and such when they are installed into the application. My question is how to go about using LLBL to do something like this.

Can I seperate my database tables into seperate projects in LLBL and have a class in one LLBL project inherit from a class in a different LLBL project? Would the LLBL work correctly when the plugin is installed. When someone is searching for items to order, can I tell it to bring back all "OrderableItem" instances and when the plugin is installed it will know to include it in the search? I hope I have explained it well enough to understand.

Thanks in advance.

Hi, there. Well, off the cuff you don't really want to use inheritance for what (it sounds like) is primarily a difference in attribute value. If the "ClothingOrderableItem" and the "ElectronicOrderableItem" actually have different attributes (not just different values in the same attributes) then it makes sense to use inheritance.

A plugin architecture is, by definition, a dynamic system. So, your plugins will have to understand the additional attributes innately, while hooking to a system that works dynamically.

In LLBLGen Pro, there is a Fields object which allows for late bound access to fields. I believe there are also GetDependantEntities() and GetDependingEntities() methods as well that may be useful for late bound access.

You will not be able to get strongly-typed, early bound access to LLBLGen entities however, as, since the data access and domain infrastructure is generated as a unit per schema, you can't actually generate the entities without them being a part of the final schema.

Now, with your plugin idea you can go through a registration process wherein the appropriate DDL is executed against the database, the project file is loaded, then refreshed with the schema changes, the code regenerated, then dynamically compiled and linked back into the main system. However, once the DAL assemblies (DatabaseGeneric and DatabaseSpecific) are loaded, I believe they are locked until the process shuts down. You'd have to have some sort of external bootstrapper kick in, ask the main process to shut down gracefully while the regeneration process is kicked off and then reload the main process which would then reload the newly compiled DAL.

A lot of work.

I'm not sure the plugin idea is the best direction given the amount of work required, the limitations of the systems involved, and the potential return, but I don't know anything about your requirements. However, if you want to implement a dynamic attribute system, there are other ways of doing it...

Jeff...

Thanks for the reply Jeff.

Here might be a better example of what I am looking to do. The system needs to allow the user to add multiple different items to their cart and place the order for them. One item might be something stored in the warehouse. Another item they may want is a CD-ROM with files they have selected. Another one could be a document they want printed and shipped out. Another one may be a dynamic document where they supply values to variables to generate the document from a template. All of these things are required to be added to the cart, but it needs to be built in a way where one client has access to order items from the warehouse and others may need that and the ability to send documents out to be printed. Now these things are a little bit more than just attributes. The requirements are to have a plugin architecture where these can be added to the appropriate client. I hope I have given you a better example of what the system needs to do. I am looking for any ideas on the best way to go about doing this.

Thanks John

John You might want to look at Design Patterns to help you come up with a solution. Off the top of my head look at Factory and abstract Factory paterm...I am sure there are others.

You also might want to consider use of Interfaces which means that you will have to define you mether etc...and the implementations can then be 'plug-in' at run time.

Hope this helps

sparmar2000 wrote:

John You might want to look at Design Patterns to help you come up with a solution. Off the top of my head look at Factory and abstract Factory paterm...I am sure there are others.

You also might want to consider use of Interfaces which means that you will have to define you mether etc...and the implementations can then be 'plug-in' at run time.

Hope this helps

I have looked into a couple of those patterns and they will help do the job. I was trying to find out if LLBL has a way to retrieve and persist this kind of example, or is this something I have to do by hand.

I have looked into a couple of those patterns and they will help do the job. I was trying to find out if LLBL has a way to retrieve and persist this kind of example, or is this something I have to do by hand.

Please can you explain - call me thick, but I do not understand fully the issue now.

sparmar2000 wrote:

I have looked into a couple of those patterns and they will help do the job. I was trying to find out if LLBL has a way to retrieve and persist this kind of example, or is this something I have to do by hand.

Please can you explain - call me thick, but I do not understand fully the issue now.

The issue, or really the question, is that if LLBL has a easy way to persist pluginable components. A little bit more on the example above about the types of items to order. There would be a "ShoppingCartItem" table. Each plugin would add a table underneath that would be a one-to-one relationship and use inheritance. The "CDShoppingCartItem" table would contain the name of the CD and another table which would hold the list of files that need to be put onto the CD. The "InventoryShoppingCartItem" table would also be a one-to-one with inheritance which would contain the item in the warehouse they want to order and the quantity.

What I would like to know if there is a way for LLBL to know that when I ask for a list of all of the shopping cart items, it will bring back all of them as the specific type that they are. If this isn't possile, I have ideas on how to work around them, but I was hoping LLBL could do alot of this for me.

Syc0F3ar wrote:

What I would like to know if there is a way for LLBL to know that when I ask for a list of all of the shopping cart items, it will bring back all of them as the specific type that they are. If this isn't possile, I have ideas on how to work around them, but I was hoping LLBL could do alot of this for me.

Yes that's possible, if the shopping cart entities are in a hierarchy. You then simply fetch an entity collection of shoppingcart entities and every instance in that collection is of the type the data represents...