In a previous version of our Csla-based framework, we had incorporated a way for objects to cascade a Save() call to their child objects and collections. This method used reflection to iterate through each property and test for the ISavable interface. If it found a property implemented the interface, it passed the call to it so the child object/collection could handle its own persistance.
This approach was taken to streamline deep object models (parent->child->grandchild->etc) and to make it easier for developers to implement BO's and replaced the explicit calls to the child object's Insert() or Update() methods as shown in the ProjectTracker sample app.
One of things that we have improved upon with our upgrades based on Csla 2+ is to fully implement the data portal. Because of this, the previous code to cascade the call no longer suits our needs for three reasons:
1. The iteration takes place on the client-side of the data portal so we have to make a full round-trip for each object to be persisted. We would rather this code ran on the server-side to eliminate the extra trips through the data portal (likely to be web services for most of our apps).
2. We now have a situation where we need more granular control over which properties are to be persisted in this manner. We have some objects, due to the particular use cases, which are persistable but not as a "child" object (for instance, a Parent property). The current implementation simply looks for ISavable and, if implemented, assumes that the property's value should be persisted as part of the call to the parent object.
3. The order in which the objects are persisted is uncertain. We are developing an application in which we have (stealing from ProjectTracker) a list of Resources, a list of Projects and a list of Assignments contained by our parent object. We must persist the first two before the third in order to ensure the validity of all foreign key references when the third is persisted.
So, what would be ideal is to have an automatic way of cascading these calls to the desired child properties on the client-side in a determinant manner. The goal being to abstract this from our BO developers so that they have less to code, less room for errors and consistent implementation and execution of the code.
Any thoughts how we might go about accomplishing this (if possible)?
Don't know if this will help but this is what I did. (This is for 1.5x CSLA but the principle is the same.)
I extended the BusinessBase to have two protected members. ChildObjects and ChildCollections (List(of DBusinessBase) and List(Of DBusinessCollectionBase))
A new interface IChildSaveable is implements by both DBusinessBase and DBusinessCollectionBase
Property PerformSave() as Boolean
Property PerformValid() as Boolean
Property PerformDirty() as Boolean
Each BO then adds it's child collections and object to the proper lists when they are created and or retrieved and also sets the properties of IChildSaveable.
In the dataportal I loop threw the list to see which ones I should save.
Copyright (c) Marimer LLC