Hi,

I'm designing a solution for a future SOA environment which includes Java services in the mix. For that reason, the LLBL's default entities that inherit the base classes in external .NET .dll's is not an option, since these assemblies can't be distributed around for Java services and proper deserialization.

What I'm thinking of doing right now is this: 1. Use existing LLBL templates to create business objects (Adapter templates) 2. Write (or dig out some existing) templates for creating transport objects (TO) that map to/from directly to business objects. Each TO has only the properties exposed. This way, the WSDL exposed with services will have simple entities for consumers that doesn't rely on implementation logic. 3. Each entity (including TO) that's exposed as an input or output of service method (the roots of object graph) has to have some concurrency field (e.g. GUID) that gets edited every time prior to db write. 4. Each of the TO has to have a "DeletedEntities" collection for entities collection it references, and IsDeleted flag of it's own (similar to LLBLs RemovedEntitiesTracker) 5. When a request is received with TO: - Transform the TO to entity - Create a prefetch path based on the entity graph (some generic method that traverses the graph) - Fetch entity graph from database - Merge the fetched graph with the TO-converted one (if Id=0 -> new, if property not equal -> modified, if concurrency field is not equal then throw Concurrency exception) - Continue to work with fetched entity graph.

What I would like to know is am I reinventing the wheel here? Is there some existing solution for this scenario (mixed web services communication that exchange objects fetched via ORM tool)?

veljkoz wrote:

1. Use existing LLBL templates to create business objects (Adapter templates)
2. Write (or dig out some existing) templates for creating transport objects (TO) that map to/from directly to business objects. Each TO has only the properties exposed. This way, the WSDL exposed with services will have simple entities for consumers that doesn't rely on implementation logic.
3. Each entity (including TO) that's exposed as an input or output of service method (the roots of object graph) has to have some concurrency field (e.g. GUID) that gets edited every time prior to db write.

Those are already possible. You can look at some DTO templates out there: http://llblgen.com/tinyforum/Messages.aspx?ThreadID=13256 I think the concurrency field could be in your DB tables thus in your entities, that way you can also use it to do a concurrency check when you save the entity. If you want only that field to check the transport concurrency, then you could write a custom property in CommonEntityBase for that purpose.

veljkoz wrote:

1. Each of the TO has to have a "DeletedEntities" collection for entities collection it references, and IsDeleted flag of it's own (similar to LLBLs RemovedEntitiesTracker)

I don't know about open initiatives that support this. In some REST like approach you just need to call the verb an the data is treated according to the context. However you can implement this writing you own templates. You also could investigate whether EF SelfTracking/POCO could be useful here.

veljkoz wrote:

1. When a request is received with TO:
   • Transform the TO to entity
   • Create a prefetch path based on the entity graph (some generic method that traverses the graph)
   • Fetch entity graph from database
   • Merge the fetched graph with the TO-converted one (if Id=0 -> new, if property not equal -> modified, if concurrency field is not equal then throw Concurrency exception)
   • Continue to work with fetched entity graph.

Same as above, LLBLGen provides you with IEntity(2) objects you could use to convert from/to anything you like, but you have to implement the logic around that. Normally with templates you could do almost everything.

veljkoz wrote:

What I would like to know is am I reinventing the wheel here? Is there some existing solution for this scenario (mixed web services communication that exchange objects fetched via ORM tool)?

I think DTOs or POCOS is the answer here. The complication you are adding is the tracking for Deleted Items, which can be achieved with your own custom code for the templates, or simply by a comparison (diff between objects sent vs. objects received are the objects deleted).