Deserialize object and markold

jcbodine posted on Monday, November 20, 2006

This may be a weird one, but here goes

i have a business object "A" that at somepoint in it's lifecycle will be persisted to a series of table in a database.  However until that point in time, a user may want to save a "draft" verison.  i experimented with using a binary formatter to serialize the object to a file and that worked.  i did not like having these files all over the place, so i decided to serialize the object to a memorystream and then take the byte array and store it in a database.  i created a businessbase class "B" for "drafts" with an attribute called "objectdata" which contained the binary data for object "A".  it works really good.

however i have one problem.  whenever i fetch an instance of class "B" and then use the objectdata as a source for deserializing an object "A", it always thinks that object "A" is dirty.  is there anyway to force a "deserialized" object to be considered not dirty?

ajj3085 replied on Monday, November 20, 2006

That's not quite how I would handle it.  You probably need to relax the rules on your BO so that it can be saved... perhaps changing the errors to warnings.  You then want another proceedure that will 'promote' the object so that it is marked as final in the database.

If you do want to continue down this path, you should be able to just override OnDeserialized and call MarkOld.  But I really wouldn't recommend going down this path.

dean replied on Monday, November 20, 2006

I believe on the old forum this was discussed and it was mentioned that there is no guarantee that the formatters won't change in future versions thereby making older serialized data unreadable.

Dean

guyroch replied on Monday, November 20, 2006

I agree with both dean and ajj3085. There is no guarantee that the binary formatter currently used will forever be forward compatible - so you might be up for a big/bug surprise in the future.
 
I would definitely look into ajj3085 suggestion, I think his on the right track. No matter what the state of your object is, it's always preferred to have one and only one persistent storage layer if possible (i.e. the database).
 
Just add a boolean property on your BO called IsDraft. If set to true, be a bit more _loose_ and allow to save with warnings instead of errors like ajj3085 suggested. Then have 2 criteria objects and 2 corresponding factory methods. One that gets draft objects and one that gets _real_ objects.

Hope this helps.