Best Approach - DataMapper vs DataContractJsonSerializer

Best Approach - DataMapper vs DataContractJsonSerializer

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


mhsimkin posted on Thursday, June 02, 2011

I am working on a business object that will contain a root object and several child objects.  All these objects are rolled together into a JSON or XML string for saving in the database.  The object contains a list of custom fields that the user would like to be displayed on a profile/survey.

I'm trying to determine what would be the best approach for serializing and deserializing this object.  My choices are:

  1. The DataMapper class and a duplicate set of objects.
  2. The DataContractJsonSerializer (or the DataContractSerializer)

If I use the DataContractSerializer classes, what would happen to the various state flags and events that fire when a business object is changed?

Any thoughts/suggestions?

Thanks

marc

 

ajj3085 replied on Thursday, June 02, 2011

If you just want to persist your BO as xml, I'd just go with creating an XDocument in your DP_IU methods and having the children add their values to this document. 

I wouldn't store the result of DCS or DCJS; serialization is meant to move an object across the wire only, not to put it in a form for persistence.  you'll hit versioning problems attempting this, and possible loss of data. 

RockfordLhotka replied on Thursday, June 02, 2011

Actually DCS and DCJS are not overly version sensitive - not like BinaryFormatter or NDCS or MobileFormatter. So it isn't uncommon to use DCS for primitive persistence.

The thing is, CSLA business objects can't be directly serialized/deserialized using DCS/DCJS - you really need to define a formal set of contract types (DTOs) and serialize them.

mhsimkin replied on Friday, June 03, 2011

Thank you Rocky.

If I use the DataMapper class, will it be able to walk the object graph?

RockfordLhotka replied on Friday, June 03, 2011

DataMapper does not walk an object graph, no. It maps one object to another.

Copyright (c) Marimer LLC