IsDirty stack overflow with managed field ref to parent

IsDirty stack overflow with managed field ref to parent

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


Fintanv posted on Tuesday, August 19, 2008

I am using CSLA 3.5 for a project in which I have a multi-level object graph where the children may have references pointing back up the chain.  This is primarily so that I can access some common data I do not want to replicate in each and every child, and which is needed for updates to the database. 

I ran into an issue with the implementation of IsDirty where it queries the FieldManager.  Since there is currently no way to mark a managed field as NotUndoable, I was getting a circular reference. 

    public bool IsDirty()
    {
      foreach (var item in _fieldData)
        if (item != null && item.IsDirty)
          return true;
      return false;
    }

There is already an entry in BugTracker (http://www.lhotka.net/cslabugs/edit_bug.aspx?id=30), so this is some added ammunition to move it up the priority list ;-).  My workaround is to manage the field explicitly and bypass FieldManager, however I dislike having the dual code constructs.

If others have handled this in a different manner, I would love to hear.

Thanks, Fintan

ajj3085 replied on Tuesday, August 19, 2008

I'm really unclear on when not to use managed properties.  Currently I'm not using managed properties for anything the user can't edit or view, and is only needed as part of the objects state.  So my database id, which is always hidden, is just a normal field inside the BO.  This seems right to be because the field shouldn't participate in Undo related operations, never needs to have security checks done, doesn't get validated in anyway.. so I'm opting to save the ovehead for those kinds of fields.

I could be wrong though... I'm interested to see what the new book will have to say on the topic.

RockfordLhotka replied on Tuesday, August 19, 2008

ajj3085:
I'm really unclear on when not to use managed properties.  Currently I'm not using managed properties for anything the user can't edit or view, and is only needed as part of the objects state.  So my database id, which is always hidden, is just a normal field inside the BO.  This seems right to be because the field shouldn't participate in Undo related operations, never needs to have security checks done, doesn't get validated in anyway.. so I'm opting to save the ovehead for those kinds of fields.

I could be wrong though... I'm interested to see what the new book will have to say on the topic.

Unless you use the NotUndoable attribute, your fields (private or managed) are subject to undo. That's not new with managed properties.

Managed properties should always be used for child references. That saves you a huge amount of code and avoids a lot of common bugs made where people forget to add this or that bit of plumbing around child references.

Managed fields may be used for normal public properties, or you may use private backing fields. That's really your choice. Managed fields are a little slower, private fields won't serialize as easily to CSLA Light if you ever move to Silverlight (though they will work, you just have to do extra work in your code).

I don't use managed fields for non-public values like a timestamp or private id value. I'm perfectly happy to put them in private fields. Though there too, that will require extra work to make the object serialize properly to/from Silverlight.

ajj3085 replied on Wednesday, August 20, 2008

Thanks for the clarification! 

ajj3085 replied on Tuesday, August 19, 2008

Oh, more relevant to your post...  you already should have a Parent reference already, you just need to cast it properly.  So you shouldn't need to maintain the parent reference yourself.

Fintanv replied on Tuesday, August 19, 2008

Unfortunately I need access to the containing object one level higher than the parent collection, hence the stored ref.

ex. BO1 -> COL2 -> BO2  : where BO2 needs access to data in BO1.

W.r.t. your earlier post: Since the read only base class also includes the managed field concept, I have been implementing the read-only properties as managed fields as well.  Maybe my usage is overkill?  I do prefer the cleanliness of having a single way of treating all properties, plus since I utilize grids alot, I like the ability to supply a friendly name via the PropertyInfo (very clean way to support internationalization as well). 

-- Fintan

tetranz replied on Tuesday, August 19, 2008

Fintanv:

Unfortunately I need access to the containing object one level higher than the parent collection, hence the stored ref.

ex. BO1 -> COL2 -> BO2  : where BO2 needs access to data in BO1.

You can still do that with the built in reference. You just need to add a property but not a field so you don't have to worry about NotUndoable or NotSerializable attributes, that's already done correctly. See http://forums.lhotka.net/forums/thread/24850.aspx  I've used it and it works nicely.

Copyright (c) Marimer LLC