Readonly business objects & propertyInfo requirements

[Marjon80]

Hi,

We are starting the process to rewrite an application from CSLA 3.8 to 6 and wanted to understand what best practice and any ramifications of using auto property declarations vs property info objects in a readonly business object (think lists and some objects that hold settings/options that are held within editable objects).

A large amount of our objects has a very simple definition of Id, Code, Description, Active and we have overtime used different patterns of using code like this:

  private static readonly PropertyInfo<string> _CodeProperty = RegisterProperty<string>(c => c.Code);
  public string Code
  {
    get => GetProperty(_CodeProperty);
    private set => LoadProperty(_CodeProperty, value);
  }

and sometimes just using code like this:

  public string Code { get; private set; }

We have historically only ever used a local dataportal calls, talking directly to the database from the client application. We intend to continue doing this for now but want to ensure that if we need to introduce an application server our coding pattern doesn't cause any issues. I'm not sure if based on comments left in #2448 that we would be responsible for the serialization of these auto implemented properties.

Thanks for any feedback.

Marjon

[saulyt]

That is correct. The properties will not get automatically serialized if you don't use PropertyInfo.

[rockfordlhotka]

I do not thing that v3.8 serialized the object graph for LocalProxy like we do today, so you probably don't know whether your types can serialize or not.

Maybe you can create a unit test (or several) that Clone each root type. The clone process serializes and deserializes the object graph, and so is often the easiest way to know whether you have code that prevents cloning. Though such a unit test would need to set every field/property, then do a clone, then confirm that the cloned instance has those same field/property values.