在一些場合，我們可能需要對業務實體進行版本控制。類似于源碼管理工具一樣，可以查看歷史版本，可以回滾，可以Lock，一個業務實體對象，同一時刻只允許一個人進行更新操作。為了實現信息的可追溯性，這些功能應該是必不可少的。只是我們該在哪里去控制實體對象的版本呢？

　　我們希望將版本控制的功能，獨立于某一個具體的業務實體，這樣才可以實現最大共用和擴展性。顯然，要實現這一功能最好的切入點應該是在數據持久層，也就是在實體持久化時，我們需要有一個統一的，通用化的接口來完成，同時在這里插入版本控制的功能。無疑，這里的最合適的持久化接口應該是ORM，那就相當于我們要實現一個帶實現版本控制的ORM接口。

　　版本控制功能，我們不僅要求與數據庫無關，還要求與具體的某一種ORM框架無關。與數據庫無關，我們可以很容易通過ORM來隔立，但是與ORM框架無關，我們就需要將版本控制的功能從與某一種ORM框架隔離開來。

　　版本控制功能，是插入到ORM接口中去的，那在哪里去檢測實體的修改情況呢？一種方案是將原始數據和修改后的數據，傳入版本控制接口，由版本控制模塊進行比較，從而得出實體的變化情況。

　　另一種方案，就是在實體中插入一定的屬性變化跟蹤機制，這也是現有的ORM實體中已經有實現的一部分，不同的ORM框架在監控實體更新變化方面都有不同的機制，在NBear，LINQ To SQL，Entity Framework都有一套自己的實體屬性變化跟蹤機制。我們可以將這些不同的跟蹤機制統一起來，形成一套標準的ORM版本控制模塊的接口實現。

　　還有一些需要考慮的：

　　存儲歷史版本時，是使用增量存儲還是使用完全存儲。增量存儲，在回滾歷史版本時，就需要從當前版本起，做很多的回溯的工作，而完全存儲就可能會耗很多存儲空間。

　　在存儲方式上，我們是將它們存儲到數據庫，還是以XML文件的格式單獨存放每一個版本的記錄。

　　目前的一個存儲想法是：使用增量存儲與完全存儲共存，將每次改變的字段，以及它的原始值和新值保存到數據庫中，方便在查看歷史版本修改記錄時用。而將每個版本完整值，以一定的目錄格式，XML文件的格式保存在磁盤中，可以考慮壓縮等因素。這樣做的原因是，回滾歷史版本的操作一般是相對比較少的，但是存儲完整的歷史版本值，卻可能需要很多的數據庫空間和考慮備份的問題。假設我們以操作日期的目錄格式來保存文件，我們就可以方便的進行備份和轉移。

　　遺留問題，在ORM中，對象的關聯是必不可少的內容。對于對象之間的關聯關系發生變化是否也需進行版本控制，這樣一來，版本控制的內容就會變得更復雜和難以實現。所以暫且限定，版本控制只針對于單對象的屬性值變化。

　　以上就是ORM With versioning control的一些想法，這些想法是從Content Repository API For Java (JCR)衍生而來的。在JCR中是實現了一個自有格式(XML)的數據庫，用在CMS中存儲一些結構可變（非結構化）的內容。同時在它的功能定義中，還包括了一些傳統數據庫（或數據庫使用接口）所不具有的功能，包括：版本控制，數據變化檢測等功能。我想法，在結構化數據的存儲中，要實現這些功能，應該是在ORM上來實現，歡迎大家來討論。