我们是否需要ORM
终于，有一天，OO城程序员们爆发了，他们声称他们受够了在漫长的走到河边之后还需要游泳（ODBC类）才能到东岸泡美眉的日子。既然将大陆融为一体的地壳变动还需要等很久， 他们决定不再等待，一种叫做OO之船的东西（ORM）被迅速的制造出来并被声称可以极大的改善程序员的泡妞之路，
西岸因为OO之船而振动，OO之船的理念和设计图传遍了大陆，无数的程序员们架着因为制造者的不同千奇百怪的OO之船们开始了自己的泡妞之行。
OO之船得到了OO城船员的高度好评，但是郁闷的OO城船员们也发现，在漫长的河的沿岸，只要是程序员聚集的城市，拥有一种叫做helper桥的东西横跨在两岸。helper桥是每个OO村庄千百代河岸程序员辛苦工作的结果。与每个人都要携带OO之船不同的是，他要求每个岸边的程序员都赶到附近的helper桥，然后再利用helper桥踏上自己的泡妞之旅。
OO城的程序员因为食古不化的河岸程序员而愤怒，尤其有些破旧的helper桥居然还是使用”过程”邪教的方法制造出来的。
在等待地壳变动的日子里（dlinq，ODBMS），无数仍然使用游泳过河的西岸人观望着OO城的程序员，期待把自己解放的一天。无数的OO之船员看着自己每天背负的OO之船，思索自己是否需要每天都背着这个家伙。船，还桥 还是别的什么，才能让程序员们更轻松的赶到东岸美女的面前，程序员们困惑了。
ORM的不足
ORM构架相较传统的普通型（请原谅我使用这个词，因为我不知道该使用什么来形容他）提供了先进的“对象－关系”映射，他存在最大的意义在与试图消除关系型数据库结构与面向对象编程中不可逾越的鸿沟。与激进的dlinq，ODBMS不同，他并不试图改变目前的代码构架或是数据库结构，他只是一个桥梁，试图将复杂两个完全不同的构架连接起来并提供一种简单而便捷的手段来方便别人使用。
围绕这座桥梁，无数的人员参与了它的设计与建造，而且因为意思形态的不同，围绕ORM，他们产生了无数的话题和创意。ORM由原来的设计模式转变成为了一个庞大的构架，他向想越过对象－关系之河的人们提供工具，并采用了很多方法，试图减轻使用这一工具所带来的副作用。但是，我们真的需要ORM框架吗？
下面就本人的一知半解来阐述下ORM的不足。
ORM的核心概念是O->M的转换，软件设计因为OO，而获得极大的发展，软件开发的效率得到了很大的提升。但是一个问题被引发，OO化软件编写与关系形数据持久不匹配成为了软件开发中的一个障碍。ORM就是试图将数据持久的数据转化为OO的对象的方法方便开发。这个概念相当不错，但是在实际使用中却有着不少问题。下面我一一道来。
首先，ORM是站在“对象”的观点来观察周围的一切。但是在实际中，关系型数据库存在一些不可逾越的使得限制使用ORM必须要付出相当的代价。
我们的软件模型可能不止关注与”对象”个体的属性，而在很多情况下需要对多个”对象”的属性进行研究。
比如，我需要获知一个简单类型的值，他可能是一系列对象实例的属性集合的一个描述，比如票房排名前一百的电影的导演名。可能对象”电影”是一个拥有无数属性的对象，这对面向OO编程没有什么影响，但是为了获取这个简单的值，我必须要加载符合条件的所有电影实例来进行导演名的遍例吗？如果不是一百个电影，而是前一百万个顾客名称，我估计还是不得不去加载所有顾客。或许我们可以来对象化电影的导演名，但是如果我们需要制作一个工具，用户可以决定他关注的电影范围，来观察其任一个属性（而不是展示全部属性），我们只有加载全部对象实例了。
大量的垃圾数据交互显然自不必说，为了实现我们的目的，我们只能无奈的去复杂化我们的代码，这是我们的初衷吗？这所带来的一系列的问题由谁来买单那？
另一方面，如果我关系的简单类型的值，他可能是一个与”对象”无关的描述。比如我需要知道一个连续ID列值有哪几个缺失了。ORM就无能为力了，因为我们无法描述不存在的东西。除非制造出一个专门的对象来实现，但这也是自找苦吃的方法。
第二：
对象型和关系型的基本立足点就不一致，对象型强调的是OO,关系型的核心理念是第三范式，甚至是BCNF。因为代码需要的是简单明了的对象模型，OO拥有继承和多态，喜欢的是对象具有全面的属性。比如我设计一个汽车类，他包含汽车需要的轮胎种类，出于编程的便捷性，我当然喜欢汽车会有一个属性直接表示轮胎种类。但是站在数据库的角度上，出于扩展，简化或性能的考虑，我可能被迫使用汽车－>轮胎类型号->轮胎类型名称的设计。当然，或许这可以使用一个简单的外键级联，使”轮胎类型”对象成为”汽车”对象的属性来解决问题（这里也包含上面所说的问题，无效的加载）。但是很可能的这不是一个级联，我不希望他们使用外键关联（比如数据仓库项目）。那我就必须作出牺牲原则的抉择，OO还是Relation？这是个问题。
待续。。
周末万岁！
ORM优势和缺点， ORM为何而生，ORM与DB Helper Library
接着上面的写。
ORM优势和缺点：
优势：ORM自其概念被提出，就得到了无数的响应，花样繁多的应用框架更是应接不暇。可见，他是有其独到的优势的。那么他的优势有哪些那：
首先，ORM最大的优势。
隐藏了数据访问细节，“封闭”的通用数据库交互，ORM的核心。他使得我们的通用数据库交互变得简单易行，并且完全不用考虑该死的SQL语句。快速开发，由此而来。
第二：ORM使我们构造固化数据结构变得简单易行。
在ORM年表的史前时代，我们需要将我们的对象模型转化为一条一条的SQL语句，通过直连或是DB helper在关系数据库构造我们的数据库体系。而现在，基本上所有的ORM框架都提供了通过对象模型构造关系数据库结构的功能。这，相当不错。
缺点：
第一：
无可避免的，自动化意味着映射和关联管理，代价是牺牲性能（早期，这是所有不喜欢ORM人的共同点）。现在的各种ORM框架都在尝试使用各种方法来减轻这块（LazyLoad，Cache），效果还是很显著的。
第二：
面向对象的查询语言(X-QL)作为一种数据库与对象之间的过渡,虽然隐藏了数据层面的业务抽象,但并不能完全的屏蔽掉数据库层的设计,并且无疑将增加学习成本.
第三：
对于复杂查询，ORM仍然力不从心。虽然可以实现，但是不值的。视图可以解决大部分calculated column，case ，group，having,order by, exists，但是查询条件(a and b and not c and (d or d))。。。。。。
世上没有驴是不吃草的(又想好又想巧,买个老驴不吃草)，任何优势的背后都隐藏着缺点，这是不可避免的。问题在于，我们是否能容忍缺点。ADA代码虽然易用性很差，但是US.DoD（the department of defense）欣赏他的运算速度；.net平台很不错，但是他是MS的。^_^
ORM为何而生
在数月以前，我有幸参加了一个公司内部的组件发布会。令我深感意外的事，一向无人关心的组件发布会这次变得人山人海，在漫长的新版本介绍之后。每个开发组长都跳出来抱怨上一个版本的问题，并且宣布与刚发布的新版本也是无法满足他们的需要的。一切都是如此的混乱，以至领导层不得不采用镇压的方式来平息怒火冲天的人们。
在会后的那个晚上，我仔细回想了这次冲突。因为据我了解，这一系列的组件非常完美的完成了他所被期待的功能。可是为什么还是会被抱怨如此那。
我觉得，可能，他(组件)是没有被正确使用了。
不知道还有谁记得James Elliott的那句话，
As good object-oriented developers got tired of this repetitive work, their typical tendency towards enlightened laziness started to manifest itself in the creation of tools to help automate the process. When working with relational databases, the culmination of such efforts were object/relational mapping tools.
ORM构架只能是一个helper，他定位与此，而不是完整的数据持久层。他的设计者从来就没把他定位于取代一切的超级美女。ORM致力为长久以来的程序员与”重复劳动”的战争而助拳。与任何一个helper一样，他有自己的不足，他有优点也有缺点。
无数的开发人员试图将使用ORM的框架构架自己项目的数据持久层，很多人感受到了ORM的优势，他们欢心鼓舞。但是很不幸，也有很多人失败或是深受蹉责。
还有许多人，无奈的编写着很多ORM不适合作的事情。其实想一想，被自己舍弃了的以前的helper工具，难道真的一无是处了？
ORM与DB Helper Library：
很多人可能都接触过这类的helper，每个公司都有自己的helper。许多Helper提供了很多的强大的功能，封闭交互底层，实体类支持，提供SQL翻译功能。ORM比之这些Helper只是多提供了一层，他尝试封闭的自动化的（或是映射文件）来实现关联。以前，这都是我们手打的。（灵活替换数据库也算ORM优点，
）
问题就在与有些人发现封闭的自动化关联满足他们需要了，所以ORM对他而言是成功的。而有些人发现封闭的自动化关联不适合他们的项目，所以ORM被诟病。
写到这里，我想不用多言了。该结束了。
我的观点是ORM试图取代helper，为此提供了更多的功能。他为了应付更加严格和复杂的企业需求而不断发展，在很多情况下，这些工具开始具有自身的复杂性，使得开发人员必须学习使用它们的详细规则，并修改组成应用程序的类以满足映射系统的需要，使用它们所面临的复杂性反而盖过了所能获得的好处。在我们的大部分项目中Helper依然是我们构建数据持久层的主力，ORM或许在有些项目(模块)中可以独揽一切，但是ORM（就目前而言）无法面对一切考验。
上帝说
有一天，马可问上帝：‘伟大而万能的主啊！编程大陆的程序员们因为OO之船与helper桥而困惑。迷途的羔羊发出无望的惨叫，您为何不可怜他们。将大河消除两岸合一，或者赐于他们神奇的法器让他们渡河那’。
上帝说：‘马可，你的怜悯之心甚好。但是你可曾看到，那喧嚣的声音不是无望的惨叫，而是他们争执的喊声。你不曾了解，正因为那河，他们的生活才存在意义。即使我消除了那河，程序员们还会因为别的什么而争吵。’
马可问上帝：‘这是为什么那，难道快乐的生活不好吗？’
上帝说：‘那是程序员的宿命啊。他们因为无法克制的好奇而踏上探索之路，他们通过争执而发现方向，他们因为挫折而反省，他们为了探求编程大陆的奥秘而一代一代不断追寻。马可，总会有一天，他们会来到我们这里，这点我深信不移’
马可说：‘真是群可怜而无畏的孩子啊！’
上帝说：‘凡是追寻真理的人们都将永生，即使死去的，也必复活！’
