Using LLBLGen objects through COM ( CCWs )

Posts   
 
    
Posts: 254
Joined: 16-Nov-2006
# Posted on: 04-Jun-2007 14:28:36   

Has anyone much experience in doing this? We have a legacy application which is written in ASP and although were gradually migrating pages to ASP.NET, this is a huge task.

On some ASP pages it would be more productive to simply keep the existing ASP code however I would like to use generated LLBLGen entities ( currently it uses far too much inline SQL ).

Has anyone used LLBLGen through COM, modified the generated code using the templates or find any specific issues? Obviously COM clients not being able to call overloaded constructors need to be worked around so we can load entities from primary key values e.g. using the public constructor and calling another method to load the object.

It is usually best practice when developing .NET components to be callable by COM clients to use various attributes such as ClassInterface to specify the class uses a specific interface for the COM definition exposed. e.g.

[Guid("45AC1550-E7B9-4a71-9506-6537BCC44F31")]
    [ClassInterface(ClassInterfaceType.None)]
    public class PurchaseOrder  : IPurchaseOrder

Alternatively we could build LLBLGen COM interop helper methods which take a specific object value as the constructor and pass this into it to allow COM clients to easily create objects using the overloaded constructors e.g.

Dim oEntityCreator
Set oEntityCreator = CreateObject("LLBLGenEntityCreator")

Dim oPurchaseOrder
Set oPurchaseOrder = oEntityCreator.CreateForID("DataAccess.PurchaseOrder", lOrderId)

In this way the prog id of the entity is specified together with the entity identifier.

Thoughts?

jtgooding
User
Posts: 126
Joined: 26-Apr-2004
# Posted on: 04-Jun-2007 14:53:42   

I haven't tested the latest versions with COM But we found too many issues trying to expose the LLBLGen objects directly through COM. Numerous overloads, enumerations etc. just don't translate well through COM.

My solution was to create an Interop layer to manipulate the LLBLGen objects, so our structure looked like this:

Legacy App Interop Layer Business Layer LLBLGen Created Code

Depending on which model you use to generate the code 2 of the logical layers can be combined, this is just how we did it.

Legacy App - enough said Interop Layer - this exposed an interface for the Legacy app to instantiate and manipulate business objects. Business Layer - this is where we encapsulated our business logic LLBLGen - Enough said.

Abstracting in this manner allowed for a smooth conversion path, to replace piece by piece logic from the legacy application, once the application is fully converted you just remove the interop layer and call the business layer from the new .Net application.

John

Posts: 254
Joined: 16-Nov-2006
# Posted on: 04-Jun-2007 15:48:18   

Well I'm actually getting more and more familiar with the template studio so would be looking to change the generated code through new templates if possible to make the entities COM friendly or if possible build the COM interop layer automatically.

I assume your interop layer essentially creates methods which wrap a few method calls to the other layers and take objects / types which are friendly for COM clients. I'd prefer to minimise the amount of work I write in the interop layer though and re use the existing code as much as possible.

What specific issues did you have with enumerations as these should be exposed through the generated COM type library e.g. an enum State with a value ForApproval would have a generated value State_ForApproval.