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?
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.
Copyright (c) Marimer LLC