Hello,
I already successfully used CSLA in one project and it saved me a lot of time. So thanks again for this great framework!
On another project I also would like to benefit from CSLA and make use of the nice binding, serialization, validation and authorization stuff. The problem is that I need a completely different way how changes are persisted. Actually there is no database or any kind of file store on the server side, the changes made on the client should just be transferend to the matching object instances on the server. Beside that I already have other WCF services running for realtime data push&pull and other things. Therefore it could also easily host the "configuration service".
I already designed the mechanism how this could work, but I somehow need to completly disable the DataPortal and replace it with my own implementation.
I had a look at the CSLA sources and my first thought was to just override the BeginSave and Save methods of the base classes that I need (BusinessBase and BusinessListBase). Unfortunately I don't have enough overview to be sure that this are all important places where DataPortal calls are made, that I need to replace/override.
Best regards,
Patrick
The data portal can run in "local mode", where the "server-side" code runs on the client. The reason for this capability, is to support your scenario.
Instead of throwing out the value and consistency provided by the data portal, use it to manage your client-side object lifetimes, and implement your DataPortal_XYZ methods to call your existing WCF services.
This is technically called an "edge application", where your client application is on the "edge" of a service-oriented system. This is a supported scenario, that is quite frequently used, especially in enterprises where SOA has been widely adopted.
Thanks for your quick response.
I thought the same in first instance, but in my case I really don't see any benefit in using the DataPortal (even though I generally like it really much).
Actually it isn't really an "edge application", it's more the center ;) It's an service that steers different kind of hardware devices and streams it's data. It's network comminication stuff is more or less hidden from the "normal" developer. Much like in CSLA.NET. The important part is that it has to work a bit different in some points than most other common applications.
The problem is that I really don't get more consistency when I use the DataPortal, because I have to implement my own version of it anyway, which has additional features (atm it's just called Mediator) . For performances reasons I can't always serialize whole object or object trees. Therefore one thing what my Mediator does is to just forward calls to the matching remote object on the server (if it is a remote object) without creating any new object instances and without any serialization (except possible function returns/parameters).
Of course you are right I could theoretical call my Mediator inside the DataPortal_XYZ methods, but in this specific application it would be more confusing than consistent. Already the availability of a "Save" method is somehow odd, because nothing gets saved really. At least it just applies settings to hardware devices, which are gone as soon as you turn it off.
I looked a little bit deeper into the CSLA sources and I think I actually would need something like the following:
For my feeling there could be one more base class in the object hierarchy of the main CSLA base classes.
Hi,
I just want to add:
1. When using LocalPortal you get your objects by reference down to the DAL layer.
2. Set CslaAutoCloneOnUpdate = "False" in <app>.config
With 1 and 2 the only serialization to occur is N-Level undo.
And Save will no longer clone your object and rather send the Root object directly to the DAL layer in process and by reference.
Remember - the DataPortal inb LocalProxy mode is a "logical" boundry between the BO and DAL code and with every layer running in process on your client.
DataPortal combined with ObjectFactory and Factory classes may give a "kind of IoC" functionality (or you can even use an IoC container by implementing your own custom ObjectFactoryLoader).
So what happens in this scenari when you call Save is:
a. No clone of the BO
b. The "root" object is sent to DataPortal_XYZ or ObjectFactory.Update method by reference.
c. How you implement fetch/create/update/delete is all up to you.
Copyright (c) Marimer LLC