ORM的探索之路和感想

从我自己用Orm技术的经历谈一下自己的感受。

很早就接触到了orm的感念，也简单试用一些orm方案和代码生成工具，后来因为把精力转移到了配置管理上，就把orm放下了一段时间。05年年中去coderush的官方网站上闲逛得实在无聊了（等了很久都没有发布新版的coderush）就把xpo下载了下来消磨一下精力 ，结果一发不可收拾，开始投入大量的精力去关注、研究orm技术。

可能自己有严重的爱屋及乌习惯，我研究最多的还是xpo，专门下载（有的版本是反编译出来的）了源码来分析。xpo使用不难，但是读别人写的代码就太痛苦了，尤其是没有一行注释的代码。平时自己写程序时生怕注释写的不够详细，看到xpo里没有一行注释，但是杀人 的心都有了。一边走读一边注释，连续看了一星期后放弃了，不过对它的思路是理解了。因为公司对代码的安全性、合法性要求很高，不敢把别人的orm方案直接拿来使用，而且那些方案都过于豪华了——我只需要一个能上班的代步工具，没必要用一辆劳斯拉斯 。

于是，自己开始动手写自己的orm方案，思路就是xpo那样的：反射+Atttribute。当时有个时间比较紧，项目各个模块的功能要求比较类似，orm可以大规模的消减重复劳动，我自己做的orm方案就在这个项目的开发过程中诞生了。当时为了尽量的减少代码量，把一些验证、重复性较强的业务功能也全做到了orm框架中，大大的减少了项目整体的代码量，终于赶在项目节点时间前完成了开发。但是这个orm框架通用性就打折扣了，有好几个同事跟我要这个orm框架程序，我只能把整个项目给他们让他们自己拆出一部分来用 。

今年夏天有段项目的间歇期，加上前几个月学习开发模式的经历，决定把自己的orm框架重构一遍，主要是提高通用性，引入和增强了设计模式的应用，让整个方案条理更清晰些。重构快结束时来了新项目，一个半月时间加班加点把项目完成了，对新版的orm框架自己感觉还不错，同事也觉得省了不少力。（后来分析了一下，加班的原因是页面层的通用性太差，纯体力的劳动太大，这个问题以后一定得想办法解决。）

目前流行的几个orm方案多少多看过一些，都没有实际的项目经历，只是把它们当作教材来学习和借鉴。经过这么一番“学习——自创”过程后，自己对.net的理解加深了、技术也有大幅度提高（深感欣慰），同时受自己的影响采用orm技术开发的项目在部门全部项目中比重越来越大。我自己做了三个，另外两个关系比较近的项目负责人各自做了一个，其中个项目负责人的项目是近300万的大项目（纯软件），他采用的方案是：我的那个orm框架的第一版改良+微软的DBhelp。我们几个人也坐在一起讨论过，认为ORM目前最大的好处就是减少了重复性的coding工作，简化了项目开发过程和难度，提高了项目组人员利用率（即使新手也可以放心让他做了），除此之外谈ORM重要性就过头了；同时认为一定要有自己的东西不能完全的拿来主义。

无论哪个ORM方案用的得当肯定是能提高项目的开发进度，但是作为一个项目成功与否，开发过程所占的比例并不是很大，就不谈软件工程上那么多阶段了，就是一个后期维护都能拖死人，维护期间用户再频繁的提新需求就更是恐怖了。因此，任何一个ORM方案在项目人员面前绝对不能是黑盒子，你不知道将来会出什么异常和缺陷。尤其在某些特殊行业（军工、政府等重要部门），用户更不能允许有黑盒子的现象，就是开源的东西都会一再的审核。另一方面，目前知名的orm框架为了满足各种可能的需求，造成框架越来越复杂、越来越庞大，经常我们的项目达不到那个复杂程度或者说即使用传统的方法来解决也不会增加工作量和难度，这时候我们就要认真思考一下如何对待这些“名家”了。

我的态度是：ORM技术作为一项开发技术，它有自己应有位置和目标，绝对不能神化它。ORM 不是万金油，不是仙丹。

转载于:https://www.cnblogs.com/tidy/archive/2007/01/01/609646.html