在一些场合，我们可能需要对业务实体进行版本控制。类似于源码管理工具一样，可以查看历史版本，可以回滚，可以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上来实现，欢迎大家来讨论。
