Single Child Object Property

comp1mp posted on Friday, August 09, 2013

I am using CSLA 3.8.4

I have come to the following conclusion, but wanted to soundboard.

CSLA does not support null property semantics, or the idea of single child object property being optional. For all intents and purposes an instance of the property must always exist (even if the instance creation is deferred). CSLA's internal code requires the existence of an instance in order to work properly for business object metastate management, undo, binding etc.

Is my conclusion correct? Am I missing something?

Here is what I need to accomplish.

I have an editable root object that has an editable child property (contact).

It must be exactly one contact, not a list of contacts.

By default the contact is null.

If the user checks a checkbox, an instance is created. (Unchecking returns to null)

Rules run only if an instance exists.

CancelEdit will return the contact to its initial state (not n level undo, just single edit cancellation)

If the contact is null no database record should exist.

Can the above be accomplished? As an aside, does CSLA 4.x support provide better support for the single child object properties?

ColourHaze replied on Friday, August 09, 2013

Hi,

Considering the null value for the child, you could consider the applying the null object pattern. I have to admit that I haven't used it in context of csla before, but I think it can work without any problems. It might require an extra base class or interface though.

regards,

comp1mp replied on Monday, August 12, 2013

ColourHaze

Hi,

regards,

Hi,

Thanks for the reply.

Without going to deeply, I believe that you still run into the same issues with the null object pattern. In all CSLA sample code I have seen for a single child object property, there is no property setter, just a getter. I believe the reason for this is changing that object references leaves CSLA in a bad state. For example, setting the property which was previously a real contact to an instance CONTACT_NULL, loses the old reference and thus leaves an orphan contact record in the database.

JonnyBee replied on Sunday, August 11, 2013

I believe you can accomplish this by making the Contact property of parent defined as

private backing field
mark the field as [NotUndoable]
make sure to upgrade the EditLevel when child is created.

This will eliminate the undo / EditLevel problem.

To control valid (broken rules) you must override IsValid and add check for Contact != null && Contact.IsValid

There is some challenges concerning DataBinding on an object that is null - but that is a whole other issue.

comp1mp replied on Monday, August 12, 2013

JonnyBee

I believe you can accomplish this by making the Contact property of parent defined as

private backing field
mark the field as [NotUndoable]
make sure to upgrade the EditLevel when child is created.

This will eliminate the undo / EditLevel problem.

To control valid (broken rules) you must override IsValid and add check for Contact != null && Contact.IsValid

There is some challenges concerning DataBinding on an object that is null - but that is a whole other issue.

Hi Jonny,

I had seen this in other posts.

If I save this child, when I fetch it how do I delete it?

I notice that all CSLA example code for single child object properties only have property getter. Does the above pattern allow me to call delete directly on the child object?.

Does the above pattern support:

Adding new contact, calling CancelEdit on the root object, and rolling back the contact to null?

While editing root object with existing contact, deleting the contact, calling CancelEdit on the root object and rolling the contact back from null to the original value?

Thanks!

JonnyBee replied on Monday, August 12, 2013

The Undo part would not work tho with my first post.

There is on more alternative route you could take.

make child object a private backing field (so it is not included in parent.IsValid)
do NOT mark private backing field as [NotUndoable] so it is included with BeginEdit.
once a child object has been created it is there (and holds it data value - not to be reset to null).
override CanReadProperty of parent to return false when checkbox datafield is not selected.
This will make the GetProperty method return the default value for the object (null) while still keeping the actual object inside the object graph - thus masking the actual field value to anyone that use the object/property.
override IsValid method of parent to only check for child.IsValid when checkbox datafield is true
override PropertyHasChanged to call MarkDeleted on child when property is checkbox datafield and child has value (as PropertyHasChanged is ONLY called when field value is changed- remember DataBinding may call the property setter many times with the same value)
when using DataPortal.Child_XYZ method the Child_Delete method will be called when existing object and has IsDeleted = true - or else when has value call Child_Insert/Child_Update (just skip the MarkOld in previos part and make this a custom logic of the Save DataAccess).
and Undo mechanism will work as expected.