Q: I am on a large C# project with a fortune 500 company, and one of our first design challenges is how to persist large, complex objects. We have 1000's of users, so bw is an issue. When a user requests this object to edit, they may only edit one field within on of the many aggregate objects. Do you of any efficient design patterns for storing only what changed, instead of resending/restoring the entire object?


This is an interesting question. I'll give you my opinion, and then readers can chime in if they have any other suggestions (you should probably give their responses more credence than mine...)

I like using serialization when I need to send live objects over a wire, or when the objects are tiny, or when I don't care about performance. But I'm an old database guy (in both senses of the word "old"), and this is the sort of situation that is tailor-made for using a database, with a separate column for each field. That gives you the ability to update a single value quickly and easily. To get a minimal update, you will need some sort of change tracking...

You can get that through the .NET dataset class. I'm not a big fan of dataset, as I like to write much more close to the metal, but it is convenient to use and it has built-in change tracking. Another option is to write it yourself for each object - setting a property also sets a modifed bit, and when you update you put all those bits together into a SQL query. It's tedious code to write but not very tough. You could also do something where each object has a reference to a "Modifications" class. When a property is updated, you tell the class that the column updated is "Name" and its new value is "Fred", and it stores all the update information away, and when you go to commit the update, it strings it together in proper SQL. That's probably better than the custom way.

Those are my quick thoughts. What do others think?