Serializable property in editable root BusinessListBase

[michaelcsikos]

With an editable root BusinessListBase I can't see a way to remember something such as:

public MyListTypeEnum Type { get; private set; }

The value is lost in translation. This can sometimes be solved with a generic base class and an abstract property, but it's more painful to implement the UI. Are we meant to have a parent BusinessBase and move the list down a level?

[rockfordlhotka]

I think what you are asking is for properties and business rules to exist in BusinessListBase?

#1830

[michaelcsikos]

OK, in this case, I don't need rules, just ReadProperty and LoadProperty.

[rockfordlhotka]

It is all the same package of work though - to basically merge BusinessBase into BusinessListBase. Or visa versa.

This is something I considered way back around 2001 or something, but it made no sense at the time since there was no data binding framework that supported the concept of properties on a collection.

These days, everything except Windows Forms does support that concept, and so one could argue that BusinessBase really isn't necessary anymore, if only BusinessListBase supported read-write properties.

[michaelcsikos]

How do the private members in BusinessListBase survive the trip from server to client?

[rockfordlhotka]

A solution for CSLA 6 is to remember that everything is serialized via MobileFormatter, which means that all the base types ultimately implement IMobileObject - including BusinessListBase.

So you can override the get/set methods for field values:

    protected override void OnGetState(SerializationInfo info)
    {
      base.OnGetState(info);
    }

    protected override void OnSetState(SerializationInfo info)
    {
      base.OnSetState(info);
    }

Then you can get/set your property or field value(s) as necessary in the serialization stream and they'll flow through cloning and the data portal.

[michaelcsikos]

Ah, looks like you were answering my question before I asked it! That will solve my problem.