Feature request: New RelationshipType for FieldManager

Feature request: New RelationshipType for FieldManager

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

joemorin73 posted on Thursday, July 15, 2010

I was wondering if it's possible to add an additional relationshiptype to the enum to allow the exclusion of CSLA objects from being updated.

I have a child object in a class that I use as a reference.  My parent class will refer to it, but I do not want .Save() to call the update on the class.  I tried to find a way to do this via RegisterProperty, but I noticed the framework will update all IEditableBusinessObject and IEditableCollection in the FieldManager's collection.

My current solution was to simply make an unregistered private field which prevented CSLA from tring to save the object.

Should this be the preferred method, or would a relationshiptype bit be better to flag what we don't want saved?

RockfordLhotka replied on Thursday, July 15, 2010

There's a big difference between a containment/aggregation relationship and a using relationship, and the type of relationship should be reflected in your object model.

When an object maintains a persistent reference to another object, that's an implementation of containment. The other other is part of the containing object. CSLA supports this type of relationship through managed properties. But even if you use a private field to implement the same thing, you are creating a containment relationship.

A using relationship should be implemented differently, and shouldn't involve one object having a persistent reference to another object. Nor should one object expose a property so code can navigate to the used object - those sorts of things are not part of a using relationship implementation.

Instead, the object using another object should have some formal way to get access to the used object when necessary. This is typically done through a factory method, IoC, a locator service or other techniques. Another technique is to have an over-arching unit of work object for your use case, where this UoW object retrieves both the using and used object, and acts as sort of a local locator service so the using object can find the used object.

If the used object is read-only and (generally) unchanging, you can implement caching in your factory method to avoid re-fetching it on each use. I do this quite frequently, and discuss the technique in Expert 2008 Business Objects.

Copyright (c) Marimer LLC