EditableRoot containing referenced ReadOnlyRoot

EditableRoot containing referenced ReadOnlyRoot

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

rshuck posted on Wednesday, December 18, 2013

I wanted to add what seemed a simple enough relationship property to an EditableRoot object but have come unstuck at the first hurdle.

An example would be an editable Project with a read only ProjectStatus, the project is editable and so is which status is assigned but not the status itself.

I can see three scenarios but each one has it's own negative effects.

EditableRoot contains ReadOnlyRoot property - roots are not supposed to own other roots

EditableRoot contains ReadOnlyChild property - the read only object is not a really a child object

EditableRoot contains Id of ReadOnlyRoot and has a reference to a ReadOnlyRoot - Id could be set to an invalid value and would require extra checks to ensure it existed.

JonnyBee replied on Thursday, December 19, 2013


In general terms - be careful on making using or intergraph references. CSLA defaults to owning references (ie a graph structure - somewhat similar to an XML document). This is in part due to serialization / deserialization on the wire and in BeginEdit/UndoEdit to restore values.

The Using CSLA 4: Creating Business Objects ebook discusses these references and how to implement them.
Se http://download.lhotka.net/Default.aspx?t=UsingCsla4

So my general recommendation is to use value references - ie: EditableRook contains the Id of the item in a list and if required add a BusinessRule for Validation.

We often use a Unit-Of-Work pattern (UOW) (somtimes also called Use Case Controller pattern) with a ReadOnlyRoot object that contains both the EditableRoot (and children) with ReadonlyLists and NameValueLists to use for the UI.

rshuck replied on Thursday, December 19, 2013

Hi Jonny

Thanks for a perfect explanation.  I do have the books and videos and have read them so many times I am embarrassed.

The reason for my pause in implementing a foreign Id to an object was it looked scarily untyped, introduces dependency on another object's data as opposed to just the other object and open to abuse (by myself) later on.

Code such as

ProjectEdit.Status = StatusListViewModel.Current

looks nicer than

ProjectEdit.ProjectStatusId = StatusListViewModel.Current.Id

I know I can have my cake and eat it by having Id and ProjectStatus in my ProjectEdit object but would have to disable serialization, lazy load and sync the two together and I believe that your suggestion of using the UoW pattern would be easier to maintain.

Copyright (c) Marimer LLC