Save and retreive CSLA Business Objects to database field issues

Save and retreive CSLA Business Objects to database field issues

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

alsnow posted on Tuesday, February 13, 2007

I have been using CSLA 2.0.2 in a new application where the business objects are pretty complex consisting of a lot of properties and child objects. I was then serializing the objects and saving them in to fields of a database record. That worked great until I upgraded to CSLA 2.1.3. Of course the serializer can't find the 2.0.2 assembly and wont deserialize in to the 2.1.3 object. Is there anything I can do to prevent this from happening each time I update the CSLA? XML formatter wont work -- no public constructor. Cans anyone think of a safer way of serializing the CSLA business object to a database field? There is so much data in the objects that there is just no way to break it out and save to individual fields. Comments would be appreciated.

Al

RockfordLhotka replied on Tuesday, February 13, 2007

Using the BinaryFormatter for long-term storage is a bad idea. Microsoft recommends against it, I've recommended against it and everyone I work with when writing and speaking recommends against it.

The primary reason is exactly what you have encountered: it is version sensitive.

If you insist on going down this road however, there were some changes to the BinaryFomatter in .NET 2.0 that might help you. It is possible to tell the serializer not to store version data in the byte stream. It is also possible to mark fields as optional, so the serializer is more tolerant of whether the field is there in the object and/or whether the field data is there in the byte stream.

You are left, of course, to manually figure out how to detect what fields are missing, and what you might do about those missing values.

It is also the case the the NetDataContractSerializer in .NET 3.0 works much the same way. It has comparable functionality to the BinaryFormatter, but generates XML instead. It has slightly better versioning capabilities than the BinaryFormatter, in that it will at least dump any unrecognized fields from the byte stream into a dictionary. You have to find and use them from the dictionary, but at least they aren't dropped entirely.

But even with .NET 3.0, it is not recommended that the NDCS be used for long-term data storage. Like the BinaryFormatter, it should be used for transient data serialization only.

alsnow replied on Tuesday, February 13, 2007

Thank you for responding so quickly. I agree that the binary formatter
is not great but the sheer amount of data data fields that have to be
stored makes it almost essential. I am using .NET 2.0. How do you tell
the formatter to not store the version information? Do you just set the
formatter to: Formatter.AssemblyFormat =
Formatters.FormatterAssemblyStyle.Simple prior to serializing? The VB
docs are not real clear.

BTW I bought your 2.1 handbook yesterday. Thanks for the extra info.

Thanks,
AL

RockfordLhotka wrote:

> Using the BinaryFormatter for long-term storage is a bad idea.
> Microsoft recommends against it, I've recommended against it and
> everyone I work with when writing and speaking recommends against it.
>
> The primary reason is exactly what you have encountered: it is version
> sensitive.
>
> If you insist on going down this road however, there were some changes
> to the BinaryFomatter in .NET 2.0 that might help you. It is possible
> to tell the serializer not to store version data in the byte stream.
> It is also possible to mark fields as optional, so the serializer is
> more tolerant of whether the field is there in the object and/or
> whether the field data is there in the byte stream.
>
> You are left, of course, to manually figure out how to detect what
> fields are missing, and what you might do about those missing values.
>
> It is also the case the the NetDataContractSerializer in .NET 3.0
> works much the same way. It has comparable functionality to the
> BinaryFormatter, but generates XML instead. It has slightly better
> versioning capabilities than the BinaryFormatter, in that it will at
> least dump any unrecognized fields from the byte stream into a
> dictionary. You have to find and use them from the dictionary, but at
> least they aren't dropped entirely.
>
> But even with .NET 3.0, it is not recommended that the NDCS be used
> for long-term data storage. Like the BinaryFormatter, it should be
> used for transient data serialization only.
>
>
>
>

RockfordLhotka replied on Tuesday, February 13, 2007

Yes, that is correct regarding the BinaryFormatter.

phucphlq replied on Tuesday, February 13, 2007

Can i "zip" it before send to client?

RockfordLhotka replied on Tuesday, February 13, 2007

Zip the byte stream generated by the BinaryFormatter? Sure - there's built-in compression support in .NET 2.0, and there are libraries you can purchase from n/software and xceed (and others I'm sure).

You can create your own data portal channel, somewhat like my web service channel implementation, where you manually run the BinaryFormatter, then run the compression code, then send the compressed data over the network.

Copyright (c) Marimer LLC