Implementing History model

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.

Over parametrized coding

Some people are used to avoid hard coding in every case they encounter. This extra avoid of hard coding leads to over parametrization. Everything is parametrized in constant classes and config files. Coders and method implementers should imagine every situation that a parameter can take. They must write extra if’s and over weighted switches just because of a parameter that in real world will never change in several years and will never change in many many installations.

Over parametrized coding is against KISS principle. It encourages to write complicated codes while they could be simpler codes.