CSLA Design Issue

ixman posted on Monday, February 25, 2008

Hi!

We are trying to build some kind of a logging service in our application. This service listens to all property changes in the loaded and created business objects and keeps a log with old and new values. When the object is saved (ISavable.Saved event), the log entries are persisted into the database. The problem is that the "Saved" event is called only if you call Save on a business object, on the client side. We looked more deeply in the architecture of CSLA and couldn't understand some bits:

Why does the DataPortal have to decide which DataPortal_XYZ method to call to save an object? This looks like an internal behaviour of the business object. Why didn't you encapsulate it in the business objects? Unless there is an issue I don't see, I think it would have been much more flexible and object oriented to have just one DataPortal_Save method on the business object that would handle the saving of the business object (insert, update or delete). Also, the impact of the DataPortal presence on the architecture of the application would be reduced a lot, because of the Single Point of Contact between the client and the server. The DataPortal purpose is to switch between client/server and not to interfere with the internal logic of the business object, right?

Thanks,

George

 

ajj3085 replied on Monday, February 25, 2008

Well, the BO does decide in a way; various flags control which DataPortal method will be called.  I don't think its "less OO" either.

I think the reason its seperated is to keep the DataPortal calls simplier; having all the code in one method makes that one method pretty unwieldy, and requires you to write a lot of plumbing code (if IsDeleted call Delete, if IsNew call Insert, etc).

Also, it enables things like being able to use an attribute to control transactions or to NOT run on the server, even if the remoting server is enabled.  All this code you'd have to maintain and remember to do.  That the framework handles it keeps more code out of your objects.

RockfordLhotka replied on Monday, February 25, 2008

Andy is exactly right. In older versions of CSLA the data portal did less (though it has always supported the four CRUD methods - it is a data portal after all ).

But the result was that all DataPortal_Update() methods had this big ugly nested if-then-else structure - a no-no in OO terms, and just plain not fun code to write/debug dozens or hundreds of times in an application.

Pulling that nested if-then-else structure into the framework reduced and simplified normal coding in objects. And ultimately it was a step on the road to where we are in version 3.5, where the data portal is able to provide consistent coding structures for root and child objects - further reducing/standardizing code to make development/maintanence easier and cheaper.

For logging though, look at the pre- and post-processing data portal methods. They exist specifically to enable things like logging. Though to be fair, prior to 3.5 they didn't have enough information in the args parameter to be real effective . But in 3.5 the operation performed is passed in the args parameter, so you can more effectively react to the request.