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

作者 Steven Robbins 译者 郭晓刚 发布于 2008年7月26日

领域

企业架构,

运维 & 基础架构,

过程 & 实践,

架构 & 设计,

语言 & 开发

主题

面向对象设计 ,

对象数据库 ,

Hype ,

数据库 ,

LINQ ,

领域建模 ,

架构 ,

声明 ,

设计

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

译者 郭晓刚 是InfoQ中文站架构社区编辑，创建并终结过数家软件小企业，翻译过多本技术书籍。

1. 返回顶部

   角度不同

   发表人 郭 名讳

   关键还是在于思考问题的角度不同，数据库设计人和对象设计人思想上就是不同的的，数据人只关注如何合理存储数据，而对象人只关心如何将业务领域映射成对象。

   回复