并非针对ORM

声明：以下观点仅限于个人思考。我个人在OO方面的开发经验其实相当匮乏，因此必定有不当之处，希望能与各位牛人展开理性、文明的讨论。

我觉得采用什么技术从根子上来讲，并不重要，真正的根源是人。人类社会的技术发展到现在，真正好的技术，其价值的体现，和对其的评价，都是建立在它能够满足人群需要这个基础之上。而这个人群是有其特定环境和背景的。时代不同，地域不同，人群构成不同，需求也就不一样。同一项技术，也许在某些时段被某些人群奉为圭皋，而在另外的时段或者其他的人群看来，也许就被视如弃履了。

基于上述观点，并结合我们软件行业的实际情况，我认为：软件行业，在披着的所谓“高科技行业”的外衣下，真正具有的是“服务业”的内核。软件行业存在的重要前提、核心价值、长远使命、根本目标之一，就是为其他行业提供服务，以满足其他行业从业人员的需要。（请注意，我这里说的是“重要前提、核心价值、长远使命、根本目标”。有些计算机和软件技术的研发，从短时期看来，好像没有什么具体价值；但经过一段时间和实践的考验，能否满足需要以体现其价值，应该会成为这些技术能否生存下去的重要决定因素[当然，这里面还牵涉到一些大公司之间的营销策略和商业竞争的因素]。一项技术刚出来，就匆忙判断它的价值所在，我认为这是非常“实用主义”的做法，不足以论之。）在这个方针指导之下，我们软件业从业人员的使命，就是为我们所认定的特定人群提供服务。认知并理解服务对象的环境和相关知识，并根据其具体情况，辨识其问题域，为目标人群选择最适合的技术和解决方案，以协助目标人群实现其价值。

回到ORM的问题上面来，用不用ORM，用到什么程度，怎么用，这些我认为都是要根据客户的实际情况和目标来判定的。为一个小小的零售店门面开发一个只有少数简单功能的、类似pos的、寿命不超过半年的过渡系统。功能少意味着其业务逻辑可能并不复杂，寿命短的过渡系统意味着可能只需要少量的后期维护工作。针对这个需求，相关的技术决策会很简单，很有可能用不上ORM，也许只用简单的access就足够满足了。而为家乐福或者沃尔玛这样的全球大型连锁超市开发pos系统，则是完全不同的故事了。前期的调研和决策过程也会变得难以预测和控制。在技术路线上的选择也是完全不同的。也许不同的业务模块，就要使用完全不同的技术方案。因此，脱离具体的环境和要求，单纯的谈论某些技术和其特性的优劣，我觉得实际意义并不大。说ORM的性能，我想要看ORM的产生的具体背景，如何使业务逻辑摆脱同关系数据库之间的耦合，这应该是ORM的催生婆之一。当ORM出现之后，开发人员终于有机会能够摆脱关系数据库的困扰，将注意力放在如何处理复杂的业务逻辑之上。引一段Martin Fowler的话吧，这是熊节当初对他采访时提到的，前几天看到，仍然觉得非常有指导意义。

记者：有的企业开发者认为，目前的企业开发效率已经足够高了，只要将目前的工具和框架掌握得很好，就可以高效率地开发出高质量的企业应用。您觉得我们的效率真的足够高了吗？
MF：不，我并不是这样认为。我们的开发效率还有很大的提高空间，尤其是如何快速、清晰地了解客户需求，并将其转化为符合要求的应用程序。这个过程对于我们目前的企业开发来说还是太慢了。
记者：可是，我们几乎不需要做任何大的设计工作，体系和架构是确定的，还有很多框架在辅助我们，并将所有有趣的设计工作都代替我们做了，在这样的开发过程中，趣味何在？
MF：如何快速而准确的满足业务需求，对业务逻辑进行建模才是有趣的事情。而像O/R Mapping这样的事情，是非常乏味而枯燥的。对我而言，绝不会认为撰写一个O/R Mapping的工具是一件有趣的事情。它与业务本身无关，而只是作为基础设施而存在。有这样的工具我觉得非常好，但是我认为更重要的，还是把握客户对业务的需求。

“记者：问您一个具体的技术问题。在很多企业应用中，人们都会开发一个数据访问层，这是为什么呢？为什么不直接在业务逻辑层中存取数据库？
MF：我本人喜欢在不同的地方作不同的事情。业务逻辑是一回事，存取数据库是另外一回事，所以它们不应该纠缠在一起。这是主要的理由。还有一个次要的理由，设计一个数据访问层，一旦数据库发生变化，移植起来会快得多。
记者：但是这样的设计也有缺点。当我们要改动数据表结构时，往往需要相应地在数据访问层做改动，接着在业务逻辑层作改动，有时甚至要改表现层。这不是很麻烦吗？
MF：哈，这是人们经常抱怨的事情，但是这就是所谓的trade-off。分层在带来一些好处的同时也带来了这样的麻烦。”

虽然里面没有具体提到ORM，但是涉及了一个很重要的观点，就是“trade-off”。现实生活中，trade-off是无处不在的，我们为了生存而上班，虽然上班这件事情违反人类自由的天性，但是为了我们自己的生存或者生活，我们不得不做这样的trade-off。“男人结婚是赌上了自己的自由，女人结婚是赌上了自己的幸福”，婚姻也是trade-off。扯远了，呵呵。

ORM，是会带来性能上的损失，但是，这点损失是可以通过补充硬件而得到补偿的。相对来说，开发人员的时间却得到了节省，效率得到了提升。短期来看，付出一点硬件成本（也许还有开发人员的培训成本或学习成本），节省了开发人员的时间成本，实际上也就是薪资成本；长期来看，开发人员应对业务逻辑的变化更加得心应手，满足客户需求变化的响应时间间隔也变得更短。孰优孰劣，我想这是显而易见的。如果，我们面向的企业级应用是以统计和数据仓库为主，客户对数据和性能的要求非常敏感，那么强要上ORM，这反而是搬起石头砸自己的脚了。

上述就是我的一些不成熟的想法，拉拉杂杂，想到哪里说到哪里。最近半年多一直在关注与敏捷项目管理、敏捷需求获取、敏捷软件开发等相关的知识和流程，这些想法也来自敏捷的原则。仔细琢磨下敏捷宣言，软件行业的先驱和大师们说的不也是怎么提升我们软件行业的服务质量么？