تکرار تاریخ

چیزی حدود سی سال پیش یا بیشتر بازار سخت‌افزار و نرم‌افزار حسابی تازه و بکر بود. منظورم زمانی است که داس، ۸۰۸۶ و جی‌دبلیو بیسیک در حال تولد بودند یا تازه متولد شده بودند. رقابت‌هایی بین تولید کنندگان مختلف وجود داشت. رقابت‌هایی که آینده دنیای کامپیوتر را رقم زدند و باعث به وجود آمدن اصطلاحاتی مثل سازگار با آی.بی.ام یا به وجود آمدن شرکت‌هایی مثل مایکروسافت شدند.

بازار نرم‌افزار حسابی بکر بود و هر کسی می‌توانست با یک نرم‌افزار ساده (اقلاً به مقیاس امروزی) کل بازار را قبضه کند. زمانی که هنوز نوجوان محسوب می‌شدم، یعنی ۱۵ سال بعد از تاریخ فوق‌الذکر، وقتی که سرگذشت آدم‌ها و شرکت‌هایی مثل آی.بی.ام، بیل گیتس و شرکت‌های گاراژی را از مجله‌هایی مثل «کامپیوتر» و «دنیای الکترونیک ؟» می‌خواندم حسابی هیجان‌زده می‌شدم و آرزو می‌کردم ای کاش من هم، هم عصر (و هم مکان) بیل گیتس، استیو جابز و دیگر پیش کسوتان می‌بودم و در آن انفجار تکنولوژیک شرکت می‌داشتم.

حدود ۱۰ سال پیش یک انفجار مشابه رخ داد: عصر دات کام. ظهور سایت‌ها و تجارت‌های اینترنتی فراوان، رشد شدید برنامه‌های تحت وب و ظهور و بلوغ شرکت‌هایی مثل گوگل و یاهو.

در خلال یکی دو سال اخیر، هم زمان با فراگیر شدن گوشی‌های قدرتمند و ظهور سیستم عامل‌هایی مثل آی.او.اس و اندروید به نظر می‌رسد باز هم تاریخ در حال تکرار شدن است. باز هم بازار بکر و رقابت شدیدی که بر سر تصاحب بازار شروع شده است. باز هم فرصتی برای کسانی که دوست دارند در این نبرد سهمی برای خود پیدا کنند.

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.