Editable Root List Base (ERLB) and BusinessListBase for transactions

Editable Root List Base (ERLB) and BusinessListBase for transactions

Old forum URL: forums.lhotka.net/forums/t/8578.aspx

den2005 posted on Thursday, February 25, 2010


    I am new in using CSLA.Net and I am looking to implement System.Transactions where involves inserting or updating multiple records of a single table or multiple records of multiple tables and you can rollback when inserting/updating/deleting a single record causes an error like a banking transaction. How can I accomplished this? What would I used? When EditableRootListBase is used and when  BusinessListBase is used? what is the difference between them? Can anyone show sample codes to 3 items? Or in order to implement Transactions I need to do manual implements just like before??



rsbaker0 replied on Thursday, February 25, 2010

Usually, with EditableRootListBase (ERLB) each item in the list is saved independently of the others.  This contrasts with BusinessListBase (BLB) where all the changes to the entire list are saved as a single unit.  A rollback when saving a BLB object would usually prevent any changes to anything in the list from being saved, while a rollback with ERLB only prevents a single entry in the list from being saved. In both cases, the descendant objects of the particular list object(s) being saved are also saved in the same transaction. So, a failure to write any descendant will rollback the saving of an individual item in ERLB, or the entire list with BLB.

ERLB was actually intended for the comparatively narrow use case of supporting editing of root items in a grid, automatically saving the item as you move from row to row.  I've used it to emulate some odd scenarios from our legacy software where we allow "part" of a list to be saved (with a flag in each object indicating whether it was saved or not), but this was not its intended use.

CSLA has no built in support for a ERLB being a child or descendant of another object, while BLB was explicitly designed for this purpose and easily supports traditional master/detail scenarios (e.g. a purchase order, which would be a BusinessBase object, containing a list of individual line items in BLB object)


den2005 replied on Friday, February 26, 2010

thanks rsbaker, can you provide sample codes how I can implement a transaction process in a blb class for multiple tables and multiple records???

rsbaker0 replied on Friday, February 26, 2010

I'll be glad to postcode samples that show specifically what I do, but I'm afraid that it would not be current enough to help. We started with CSLA 2.1, before there was any sort of connection management or child data portal.  I also manage transactions manually instead of using the TransactionScope attributes.  I haven't done much if any retrofitting as new features have been added to CSLA to make this easier.

However, if you're just now starting, I'd suggest that you take an approach (at a high level) something like this. I haven't actually done this get, so I might not have it exactly right, but I think this is close:

(1) Use managed properties wherever possible

(2) Implement Child_Update() in all of your BusinessBase (BB) child objects (BLB already contains a good implementation that you can override if needed)

(3) In your DataPortal_Update() method of your root BB, and in your Child_Update() method of your child BB's,  call FieldManager.UpdateChildren() at the end of whatever database work you do to save the target object.  CSLA will cascade this through all child BLB's and their contained BB child objects

If the TransactionScope attribute works for you, then just include it on your DataPortal_Update() method. Everything done below via the cascading Child_Update calls will occur in that transaction.

bniemyjski replied on Thursday, February 25, 2010


I also wanted to add that I tried to implement this into our templates thinking that I would have finer control to roll back the changes. I found this to be a nightmare and that the built in TransactionScope attributes work pretty good. As it manages the roll back if an exception occurs within the DataPortal method.


-Blake Niemyjski

Copyright (c) Marimer LLC