CSLA Objects Serialization

CSLA Objects Serialization

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


jpmir posted on Thursday, December 16, 2010

Hi,

Currently I'm working in a generic audit trail section of my software. The main purpose is to reflect what kind of actions users take inside each module. Since each module is supported by CSLA objects to handle all business layer requirements, I think it would be very nice to take a snapshot of the object graph and attach it to each audit trail record.

Despite the fact that this would become a very large database, there is a business requirement that drives us to reflect detailed information on data affected by users in every transaction.

Now, focusing on CSLA, I was wondering if I can relay on CSLA serializer to convert Business Objects into XML so I can store it directly into the database, and eventually deserialize them back for visualization. It doesn't matter if the deserialized version is not a clone of the original because it will be used for visualization only.

Based on this post (http://www.lhotka.net/weblog/CSLALightObjectSerialization.aspx#a058245e1-17e9-453c-bff2-b7f3200a1ed4), there are DTO's involved in the serialization process (in CSLA Light) wich seems to be perfect for this case since we are using SL4 in the presentation layer.

Am I in the right direction? Is this possible?

Is there any chance to get some hints on how could I do this?

Thanks!

Jean Paul

RockfordLhotka replied on Thursday, December 16, 2010

The serialization mechanisms used by CSLA .NET include the BinaryFormatter, NetDataContractSerializer and MobileFormatter. These are all designed to clone objects, not for persistence. Any use of the serialized byte stream for non-transient scenarios (anything longer than perhaps a few seconds or at most minutes) is a really bad idea.

The reason is that the serialized data is sensitive to the version of the business assembly and the shapes of the business objects. Unless you know your code will never, ever, ever change, you run the risk of being unable to deserialize the data in the future. Obviously that's an entirely unrealistic requirement, hence these serializers are not appropriate for that purpose.

Besides which, auditing is usually for long-term reporting, and it is hard to report against blobs. You are much better off coming up with a data strategy for your audit data that servers all your requirements (storage, reporting, etc), and writing the data into the audit table(s). Also, for the most part, data auditing is the kind of thing best done in the data access layer, not the business layer. Partially for efficiency, but also for reliability.

jpmir replied on Friday, December 17, 2010

 

Hi Rocky, 

Thanks for your quick answer. I just want to give this discussion a closure based on my own research, my opinion and of course your answer.

First of all you're absolutely right, streams produced by CSLA serialization mechanisms is not suitable for this, there is much more than simple key/value pairs for every property in the business object.

Regarding  paragraphs 2 and partially 3, you're right too, but there are many shades of gray in which -I think- this specific requirement may be. As I wrote before, we don't need to restore this XML back to the business object, you already pointed out, it'll only work if my business object never changes which is not true. I guess there will be many issues beyond version compatibility (security, convinience, etc.).  Also we don't need to report the content of this xml since we consider this to be used as part of deep auditing process, al the superficial data is being collected already (Who, When, What, and Where... this xml is what we wanted to put into the "How").

The line that kills all my intentions of arguing around was this:

"Also, for the most part, data auditing is the kind of thing best done in the data access layer, not the business layer. Partially for efficiency, but also for reliability"

That makes me realize that  I was wrong.

Thank you very much.

 

Jean Paul

Copyright (c) Marimer LLC