Issue with object state using ISerializable...?

reagan123 posted on Monday, June 02, 2008

It's me again... Quick question. We are currently implementing ISerializable in our business objects to only take our member variables. We are having a problem when we clone the object. All of the member variables that we have in our classes show up, but we no longer have the correct state for "isDirty", "isValid" etc... How can we include these properties during our serialization?

Hope this makes some sense.

Thanks for any insight!

reagan123 replied on Tuesday, June 03, 2008

Still haven't gotten anywhere on this... Here is the snippet of code i'm using at the moment... Any ideas :)

Public Sub New(ByVal info As SerializationInfo, ByVal context As StreamingContext)
            _GUID = (CType(info.GetValue("guid", GetType(Guid)), Guid))
             _firstName = CType(info.GetValue("firstname", GetType(String)), String)
            _lastName = CType(info.GetValue("lastname", GetType(String)), String)
End Sub

Public Sub GetObjectData(ByVal info As SerializationInfo, ByVal context As StreamingContext) _
         Implements System.Runtime.Serialization.ISerializable.GetObjectData
            info.AddValue("guid", _GUID)
            info.AddValue("firstname", _firstName)
            info.AddValue("lastname", _lastName)
End Sub

bwatson replied on Friday, June 06, 2008

I'm having a very similar issue when attempting to use ISerializable to "lighten" some objects; we're wanting the IsDirty, IsValid, etc. to try and keep our validation intact. Cloning the object and not including these properties renders the validation useless. Maybe using ValidationRules.CheckRules() after deserializing is an acceptable solution, just wanted some input from the forum...

Any help would be greatly appreciated.

tmg4340 replied on Monday, June 09, 2008

I'll start by saying that my info relates to pre-3.5 versions of CSLA, as I haven't had time to look at that. I would imagine that 3.5 works similarly, but that's just a guess.

It's a little tough to answer your questions, because I'm not sure why you're choosing this route. If you want to "lighten" your objects, why not simply apply a "NonSerialized" (and probably "NotUndoable" as well) attribute to those properties that you don't want to serialize? The OP doesn't say why he's implementing ISerializable, so I can't speak to that, but I'm wondering if this won't get you where you want to go.

In a more general sense, you're going to have issues if you try to apply any sort of custom serialization, for exactly the reasons you're running into. CSLA just wasn't built to handle ISerializable out of the box - that's why there is "NotUndoable" and "NonSerialized". Unless all the base properties are serialized, CSLA-based objects won't work properly. Calling "CheckRules" might help with IsDirty/IsValid, but it won't help with IsNew, IsDeleted, etc. And you need those for the DP_ code to work. Plus, you'll have issues with things like DeletedList as well, if you have collections you need to deal with.

You can certainly use reflection to get at what you need, and you could use the "Mark" routines in your deserialization code to help with the listed properties. But you would still need to include those base properties in your serialization code, along with all the other base CSLA data - if you implement ISerializable, you're pretty much on your own.

HTH

- Scott

RockfordLhotka replied on Monday, June 09, 2008

Scott is right, you would be far better off using the NonSerialized attribute.

When you implement ISerializable, you hijack the normal serialization process, and it becomes your responsibility to serialize the fields of your object. Typically this means using reflection to get/set the values (which is what the serializer would have done for you automatically).

This can get very messy if you end up reflecting against any fields that contain other objects that implement ISerializable, because you need to participate in the serializer's "fix-up" processing stage. I don't know how you actually do that, I just know that's what's required - and it is rather arcane...

If you have fields you don't want serialized - that's what NonSerialized is for, and I strongly recommend you take that approach.