First and formost has anyone complete CSLA2 templates for LLBLGen 2 yet?

Secondly, this is a long post, so if you read it, thank you very much in advance.

Background Info: The CSLA DataPortal uses the channel adapter and the message router pattern to provide a coarse grained interface to data access operations while at the same time making the network protocol transparent.

My Objective: Implement CSLA Style DataPortal with the LLBLGen Pro Adapter Pattern. Long story short, I would like to execute data access methods client side or server side, using inprocess, remoting, enterprise services, or web services as my communication transport without having to make code changes.

So, its almost like I want the best of SelfServicing and Adapter . I want to be able to tie my data access to my entity by hand coding the data access, but I want the data access code to execute in the servers context (if it has been distributed)

My Question: What would be the best approach to implementing the design of the CSLA2 DataPortal for use with LLBLGen Entitites? My biggest question regarding how I should implement this functionality is should I make my server data portal interface (IDataPortalServer) a derivative of the IDataAccessAdapter or should I simply leave the IDataPortalServer as-is and make calls into an instance of an adapter from my hand coded data access methods that live in my subclassed entity classes?

My Opinion: Part of me thinks that the IDataPortalServer interface is very functional as-is but not as functional as IDataAccessAdapter. So, I think it would be beneficial to enhance the IDataPortalServer interface to make it a bit more robust. However, by modifying the IDataPortalServer interface I now have to get way into the guts of the CSLA DataPortal architecture and make sure that all methods of IDataPortalServer can now be invoked by the concrete proxy objects and also refactor the static methods in the static DataPortal class.

My Justification / Reasoning: I have found that by designing my business objects in this fashion I can provide a framework with a low barrier to entry;e.g. the consumers of my business objects have a much easier time figuring out how to use my business objects because they can only access factory methods, or instance methods, and the complete interaction with the llblgen runtime is hidden from the consumer of the object. This approach works great, because I can have my LLBLGen saavy developers (i.e. my sr. developers) write the cool business tier, and kick the UI stuff over the fence to the less experienced offshore team.

Does anyone have any ideas, good, bad, or otherwise?

Did you talk to omar of the JCL framework? (http://www.jclframework.net)

Not yet, but thats who I was hoping would be the biggest help. Thanks for the link by the way.