وبلاگ افشار محبی

In many applications, data change is tracked. For example in TFS whenever you change any section of a work item, you can then see that change has been logged in work item history. It says that, for instance, owner of work item or time estimation field has been changed from a value to another value. Another example is article history in Wikipedia. Both TFS and Wikipedia are large applications. So what should you do if you want to add history feature for a small or medium application? Suppose your application have 20 domain classes (tables) that all of them needs to keep tracking of changes. Is it a good idea to add an extra class/table for each of them to save their history? Is there any other way?

As a solution I used a simple way: having a single class/table as main history repository, using Xml Serialization for persisting changes and Reflection to explore field changes. This way you need to use two events of your ORM: AfterLoad and OnSave or something similar. You must serialize objects in AfterLoad as old (current) value, serialize each object in OnSave as new value, saving in database and consequently showing data change by deserializing them and using Reflection to explore changes. This way has a large overload as a very long record will be saved in database with each change in data, but if history feature is forced to be done then it is a concise and centralized solution. Specially when compared to ways that developer must save history manually by adding code to each UI section that modifies data.