I would like to be able to do remoting with the adapter architecture in a simple way, similar to CSLA.

In CSLA, you can tell your app to remote to the DataPortal object simply by setting a few app.config settings. The CSLA DataPortal inherits from MarshalByRefObject.

I need to develop an application with two UIs - a web app and a win forms fat-client app. My plan is to have the web app access the DataAccessAdapter locally, while the Winforms app will access the DataAccessAdapter via remoting. The way I envision this is that both the web app and the winforms app will have references to the DataAccessAdapter, but I want the winforms app to remote to a hosted DataAccessAdapter over the network, similar to what can be done with CSLA.

My only problem is that the DataAccessAdapter does not inherit from MarshalByRefObject, therefore it cannot be remoted. I also do not have time to write a robust, remotable business layer that defines every single call to the DL that I would ever need (per the example in the customer section). The LLBL generated entities are good enough for me to use on this project.

Does anyone have an ideas on how I can do this? I have thought about writing a remotable wrapper to the DataAccessAdapter that provides the same functionality as every public method exposed by the "real" DataAccessAdapter.

Any comments, suggestions or help would be greatly appreciated.

Greetings,

I am finishing a CSLA warpper around LLBL objects utilizing ADAPTER. The two actually complement each other so perfectly that you would think the FRANS & ROCKY collaborated on the design, but I think this a pay back of following well know design patterns.

Before explaining how to approach this you have to understand the general architecture. CSLA is based on the pricipal of exposing public sharedservices to the UI (this is an industry best practice as you would see browsing some of the threads here at the Architecture forum). These service routines would call the client side DataPortal shared methods that decide to use either a local ServerDataPortal or a remote DataPortal (depending on the settings of your AppConfig or WebConfig). Once a ServerDataPortal method is called, it will use reflection with the help of the passed parameter (a criteria object or the BO object itself) to call the private methods of the business object in question (consult rocky's article at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadvnet/html/vbnet03262002.asp). These private methods would do the actual DataAccess work (be it ADO.NET or in our case LLBL code). To make LLBL's entity classes use the data portal in this fasion is not all that difficult as long as you understand what the DataPortal is really doing:

1- What will be utilized from the CSLA solution is CSLA, ServerDataPortal, ServicedDataPortal and the WebPortal (the C# bindable stuff is not needed here). The main classes needed in the CSLA project are the DataPortal, BusinessIdentity and BusinessPrincipal (and any support classes they are using). The other classes (BusinessBase, ...etc.) are not usefull with LLBL. You should customize a CSLA solution by removing all the extra functionality and keeping what you will be using

2- Create a LLBL designer project (CSLA.DAL for example) for the security tables that will be utilized in the table security used in CSLA. The two generated projects will be added to the CSLA solution. These two projects will be referenced by the CSLA project only! (CSLA project will also need to refernce LLBL's ORMSupportClasses DLL)

3- get the "Extended entity generator templates for Adapter" (from the 3rd party download site at LLBLGEN). Use these templates when generating all projects to be used by the new framework (including the security tables from step 2). This template generates extra classes in a folder (EntitySubClasses). These entity sub classes extend the entity classes generated by LLBL. These are going to be your Business Object classes. For example, when generating code for the table security (to be used in the CSLA solution itself) you will copy the generated (EntitySubClasses) folder from the DBGeneric project to the CSLA project (if you used CSLA.DAL as the root namespace for the LLBL project, you have to modify the name space in these entity subclasses from CSLA.DAL to just DAL). you must also copy the DeriveEntityFactory class from that project to the CSLA project also (remeber to adjust the namespace here and to remove these classes from the DBGeneric project). Now, all you table security code in BusinessIdentity should use LLBL code instead of ADO.NET code.

4- In solutions utilizing the modified CSLA framewrok, you will be using the DeriveEntity subclasses as you business classes. You must implement the follwing modifications for each class: * make all constructors private * create an embeded class CRITERIA that preferably inherits CRITERIABASE (see Rocky's lates CSLA Beta 1.5). A standard structure for the Criateria class is for it to have two constructores; one that takes the PK fields of your entity and the other takes a RelationPredicateBucket variable. This would allow the criteria to nicely enacpsolate LLBL's powerful RelationsPredicate bucket to perform any type of filtering * Write Public Shared service routines that expose the basic CRUD operations (I modified this so that I could write as many service routines as I want and not just basic CRUD). The code in these routines calls the appropiate routine in the DataPorat to perform the required CRUD operation. * Write a private non-shared routine for each public service routine. This private routine is what will be called by the Server DataPortal (local or remote is decided by the client DataPortal). The code in these private routines is standard LLBL code and not ADO.NET code as in CSLA.

There are some other areas that you have to consider but basically this how things will work. The resulting framework is basically CSLA's dataportal and table security married with LLBL's ORM functionality. As you must have noticed that a good understanding of CSLA's functionality and its plumbing will go along way in allowing you to build your CSLA-LLBL framework. I had fun doing it and I am hoping that FRANS would allow me to post my work for any CSLA veterans willing to integrate the power of LLBL...and beleive me ... its worth it (no more 1500+ store procedures and thats just the top of the iceburg )

OMAR

I had fun doing it and I am hoping that FRANS would allow me to post my work for any CSLA veterans willing to integrate the power of LLBL...

Of course!

Great posting, Omar, I couldn't have answered it better (also because I'm a complete CSLA newbie, I never had a look at it )

An explanation for the reason that DataAccessAdapter isn't serializable is that it contains a live connection and it is common practise to encapsulate the DataAccessAdapter with a service API, avoiding the presence of a DataAccessAdapter on the network.

Otis wrote:

I had fun doing it and I am hoping that FRANS would allow me to post my work for any CSLA veterans willing to integrate the power of LLBL...

Of course!

Just curious... Omar, are you planning on posting your code?

I'm doing something similar and would benefit from your experience.

Thanks

Just curious... Omar, are you planning on posting your code?

Yes.. I am just in the midst of a hand-over and hope to post my code sometime in the coming two weeks. I was hoping to finish earlier but those nasty issues that come up during implementation seem to never end

omar wrote:

Just curious... Omar, are you planning on posting your code?

Yes.. I am just in the midst of a hand-over and hope to post my code sometime in the coming two weeks. I was hoping to finish earlier but those nasty issues that come up during implementation seem to never end

Did anything ever become of this? I'm guessing not...

Dear Omar,

How's your CSLA wrapper around LLBL objects utilizing adapter going? Any new findings or ideas?

Just finished the LLBL templates today (including UI winforms classes). I will try to prepare some documentation to accompany the framework so as to explain the structure and how to best utilize the business objects

OMAR

omar wrote:

Just finished the LLBL templates today (including UI winforms classes). I will try to prepare some documentation to accompany the framework so as to explain the structure and how to best utilize the business objects

OMAR

WOW! Thanks Omar

Hot dog! I can't wait!

This is going to be very interesting!

Any new on this? am itching to see the code

Ryan

Sorry for the delay... I was tying up the last points to do with the WinUI framework.. I ask FRANS what is the best way to post this work

The goods are coming

omar wrote:

Sorry for the delay... I was tying up the last points to do with the WinUI framework.. I ask FRANS what is the best way to post this work

The goods are coming

Best is to create a .zip file with a readme.txt and mail it to the support email address and I'll put it into the 3rd party section Please state with it if you want to have your name and company mentioned as well.

You can also have them added to the subversion repository we have set up for templates, so others can develop them further.

Thought I'd give this thread a bump, as I am interested in using the CSLA dataportal in an upcoming project. Any news?

Ryan

Hi Omar and all the people interested in what Omar has been doing with regards to making LLBLGen and CSLA work together,

It is just another bump to this thread... Any news?

I have been working on a set of templates to integrate llblgen and CSLA, they are exceedingly rough at the moment, but I have CRUD operations remoting correctly for Entities and a corresponding set of mbUnit tests (which don't yet constuct appropriate related entities, so blow up on foriegn key constraints - stupid tests). Still have much to do - derived entity collections , CSLA business rule stuff, changing the CSLA undo functions to use llblgen's field data versioning, remoting unitofwork, remoting sprocs..

Obviously, I would like to see an intergrated transparent remoting framework in some future version of llblgen, it would be a killer feature. ( For me at least, as I am a lazy sod).

If I get something together that it publicly releasable without too much danger of being embarrisingly hacky, i'll release it.

Ryan

I just finished preparing the documentation and the source code as well as the LLBL templates and task performers. I don't know how I should post this so I will e-mail FRANS for help...

OMAR

Update: I can't find FRANS's e-mail anywhere in this forum. Can anyone pass on his e-mail please

Thanks

support AT llblgen.com will do I'll then see if I can upload it this weekend

It's live! See the 3rd party section.

Thanks a lot for this contribution to the community, Omar (and thank Bashar for me )!

Omar and Bashar,

You are great. Thank you for sharing this with all of us.

Frans, thank you for supporting this effort.

I know very little about CLSA, not read the book only picked up snippets off the web. What I'm wondering is it only useful when you need remoting or is it a fully functioning business layer in its own right?

When I got a chance I was going to take a look at the custom business manager templates currently being developed in the "Template Studio and Custom Templates" forum" are the new CLSA or JCL templates just released going to do the same job?

If they are doing the same job which one am I better off using?

I have ordered the book "Expert C# Business Objects" to start looking at CSLA. Meanwhile, I'm working with a firm in Argentina that co-wrote something called MBI (Microsoft Business Integrator) and they want to use that for my project (they also use NHibernate for ORM, but I am dictating we will use LLBLGenPro instead).

Anybody know anything about MBI??

Hi Omar,

I have a question for you: Was there a particular reason to use self-servicing scenario in the JCL implementation you've provided us with? If there was none, what are the implications of using the Adapter? Your input on this is very appreciated. Once again, thank you for the great job you have done.

Omar,

Please scrap my last post: I keep reading the docs, and now I am in the Part II.