【翻译】Object relational persistence in .Net

Introduction（背景）

在.net开发的人中，我相信大部分人都接触过或者听说过  Object persistence 框架（比如 nhibernate之类的）。我曾经用过两个数据持久化方案，一个是用 attributes 去修饰 fields/properties ，然后框架利用发射机制来获取 metadata（元数据）并持久化它，另外一个方案是将 metadata 放到外部的一个 XML 文件里面，然后依然是利用反射机制去完成对象的持久化。

Pros and cons（硬币的两面性）

因为下面的原因，我个人比较推荐外置 XML 文件的做法:

1. 即使在没有源代码的情况下，我们可以根据 XML 的定义映射到类让后存储他们（在使用第三方库的时候很有用）。
2. 映射数据不会照成类定义的混乱。
3. 当一个对象需要多个不同的持久化方案时，我们可以定义多个不同的 Mapping 文件。最起码她更具有灵活性和可扩展性。

在我个人看来，这两个方案本质上都很脆弱。它没有 type safety 或者编译时类型检查以确保映射的完整性和正确性。

Improved solution（升级方案）

我最近用外部存储 XML 映射文件的方法实现了一个 Object-relational 持久化框架原型。它具有给业务逻辑对象提供 CRUD (Create, Retrieve, Update, Delete) 的能力。我确保这个方案可以用于 System.Transaction 以提供 Transcation（事务处理） 支持。

在下图中，你可以看到一个类定义，一个映射文件和一个代码片段，它是一个 employee 类和把它存入数据库的实例。这个实现和其他现有的实现方案差不多，我用 ASP.net 2.0 编辑模式下的新特性给它添加值：

我写了一个自定义 build provider ，它映射 App_code 目录下的所有后缀为 “.orm”  的文件。这个自定义的 Build provider 可以翻译现有的映射文件，为每个映射文件产生一个封装类，确保只有定义的操作在业务逻辑对象中才能被使用。

举个例子，如果ORM文件在映射定义中只定义了 INSERT 和 UPDATE 这两个操作，那么映射文件的封装类页只包括 Insert 和 update 这两个方法。如果这个类名字没有拼写正确或者一个类有两个相同的映射定义，那么在编辑的时候就会破除错误异常。如果开发者修改了映射文件中的定义并且保存了映射文件，Visual Studio 2005 会快速识别更改，马上开始构建以便为新的方法提供 Intellisense支持（如下图）:

下图展示了自定义的 Build provider 在后台为我们生成的示例代码。通过这种方法，XML文件中脆弱的映射定义会被验证并且在编译时生成安全的代码。这样会极大的减小在开发和单元测试时候花费的时间:

Improvements（改进）

这个 build provider 可以被进一步扩展以便支持对定义在映射文件中数据库存储过程存在性的验证，以及需要的存储过层的参数正确性的验证，等等...

Conclusion（结论）

我坚信编辑时支持会给现有的 object relational persistence 解决方案提升很多价值，并且会带来很多新的可能和机遇。

 

PS：

    原文地址：http://www.codeproject.com/aspnet/orm.asp

    代码下载：http://www.codeproject.com/aspnet/orm/ORM.zip