csla and deepdata for inserts and updates

CSLA_Rocks posted on Monday, April 30, 2007

I am using Codesmith Templates to generate CSLA Business layer. However I am also making modifications in the templates so as to create a separate Data Access layer. This is inspired by the DeepData Sample. The DeepData sample explains well for Fetch command and transperancy is easily achieved between the 2 layers. However I am not able to do the same with Insert and Update commands where I will have to fill in SQL parameters from the object itself. Also if I have child objects associated then I will need to maintain transactions. How can I achieve separating the Business and Data layers in these cases?

Thanks

RockfordLhotka replied on Tuesday, May 01, 2007

Insert/update/delete are far easier than Fetch.

The same techniques used in my books work for insert/update. Your child collections/objects will all accept a reference to the root (and any other foreign-key-containing parent) as parameters to their internal/Friend Insert() and Update() methods. Each child is responsible for inserting/updating/deleting itself.

In other words, the root object calls an internal/Friend Update() method on each child collection in the DataPortal_Insert/Update methods:

  _childCollection.Update(Me)

Notice that a reference to the root object is passed to the child collection. The child collection loops through its children (and DeletedList) calling the appropriate internal/Friend Insert/Update/DeleteSelf methods on each child:

Friend Sub Update(ByVal parent As MyRoot)
  For Each child As MyChild In Me
    If child.IsNew Then
      child.Insert(parent)
    Else
      child.Update(parent)
    End If
  Next
  '...
End Sub

Each child object inserts or updates (or deletes - remember to loop through DeletedList and call child.DeleteSelf()) - itself, and then cascades the call to its child collection:

  _grandchildCollection.Update(parent, Me)

Notice how it passes both the root parent and itself as a parameter. I'm assuming that both objects now provide foreign key values to the grandchildren. The grandchild collection and grandchildren themselves merely use the same pattern as I've already shown.

As far as transactions, there are two scenarios:

1. You are using EnterpriseServices, so you can just open/close the db connection in each object and the transactions are handled by COM+ - you don't need to worry about them as long as you throw an exception if you want to fail.
2. You are using TransactionScope or Manual, in which case you should use the technique shown in the CSLA .NET Version 2.1 Handbook that uses the new ApplicationContext.LocalContext to put either the db connection or transaction object in a globally available location for use by all your child objects.