对象关系映射——用户案例研究

ODBMS.org 的 Roberto Zicari 收集整理了来自若干对象/ 关系映射技术用户的访谈和故事。这些案例主要围绕着领域模型中的对象技术与数据模型中的关系技术之间的“阻抗不匹配”。

Zicari 教授为每位用户准备了五个问题。前面的问题主要围绕请用户解释他们的应用、O/R 的障碍，以及用户如何解决或者绕过困难。后面的问题调查 ODBMS 技术是否以及如何在这些领域中发挥了作用。这五个问题分别是：

1. 请简要解释你的应用领域以及你在企业中的角色。
2. 你是否遇到“阻抗不匹配”的问题？
3. 你用何方案存储和管理持久化对象？对于在新项目里使用各种持久化方案你有何经验？在使用中得到什么教训？
4. 你是否相信对象数据库系统是解决“对象持久化”问题的合适方案？如果是，为什么？如果否，又为什么？
5. 你对对象持久化领域未来一到两年的研发有何希望？

在这项研究里，对于术语“阻抗不匹配”是这样描述的：

持久化存储数据所采用的数据模型（无论是文件系统还是数据库管理系统）如果与编写程序（C++、Smalltalk、Visual Basic、Java、C#）时所采用的数据模型有差异，就称为“阻抗不匹配”问题。

虽然对于 O/R 阻抗不匹配的定义、甚至这个问题是否存在都有所争论，但在Zicari 的调查中很多人都说曾经在项目中遭遇过这种问题。英国Iona 的技术监督John Davies 在回答“你是否遇到‘阻抗不匹配’的问题”时说：

“阻抗不匹配”是企业里的严重问题，高达25-33% 的开发时间浪费在努力将对象挤压进关系型的持久化，也就是一般说的对象关系映射（ORM）。虽然ORM 工具的例子都着力演示其简易，但现实的情况要复杂好几个数量级，于是整个ORM 的概念都没法站住脚。即便最优秀的ORM 工具也会创建出效率极低的模型，导致严重的性能问题。

Richard Aherns 是Merrill Lynch 的一名主管，他也认为确实存在“阻抗不匹配”问题。

我们绝对遇到了这种问题。对于股本衍生工具行业，敏捷和上市时间是极其重要的。经常会有新产品推出，需要灵活的技术才能适应并跟上行业变化的快速步伐。在订单和报价管理领域，我们有种类非常多的产品和资产，必须一次次维护其OR 映射，这拖慢了开发人员的生产效率，也限制了我们的伸缩能力。

德国Siemens AG 的软件架构师Gerd Klevesaat 也承认存在不匹配问题，他还说明了为何ORM 工具不一定能帮上开发者的忙。他说，“你被迫使用一种特殊的查询语言来定义查询。如果能用编程语言会比较有利，因为可以对查询语句做编译时检查，还可以利用导航（navigation）能力。”Gerd 指出已经有了一些技术和工具开始填补这个空缺，特别是“.NET 里的LINQ、db4o 里的原生查询、以及Groovy 的DataSet”。

Scott Ambler 有不一样的意见，他在 IBM Rational 担任敏捷开发的实践领导。对于“阻抗不匹配”问题，他的回答是在技术方面已经有了几种解决方案（例如 O/R 持久化框架、对象数据库、OR 数据库）。他反过来指出在大多数组织中，数据社群与开发社群之间存在“文化上的阻抗不匹配”：“这两类人对 IT 世界的观察方式不一样，两者的方式都各有优劣，而紧密合作会使两者都受益。”在 ODBMS.org 的案例研究之外，Scott对这个主题作了更进一步的阐述。

总的来说，Zicari 的研究着眼在暴露面向对象系统使用关系数据库技术的问题。研究还使我们看到，已经有很多开发及商业组织开始把对象数据库和其他对象持久化技术看作是适合解决某类问题的新兴企业技术。

查看英文原文： Object Relational Mapping - User Case Studies