ORM的优缺点

1．什么是ORM?

ORM，即Object-Relational Mapping（对象关系映射），它的作用是在关系型数据库和业务实体对象之间作一个映射，这样，我们在具体的操作业务对象的时候，就不需要再去和复杂的SQL语句打交道，只需简单的操作对象的属性和方法。

2．Snake.Net中ORM的特点与概述：

Snake.Net框架是基于.Net的应用而设计的，它和其他一些移植于Java的ORM应用构架不同，是完全根据.Net的特点设计和开发。

Snake.Net框架使用一个完整的DataSet构架，用以描述一个应用项目所涉及的数据结构（包括可描述性的表结构、关键字、外部关键字以及表与表之间的关系等）。并使用特定的方法，将DataSet构架内所描述的数据表、数据列、关键字、表之间的关联关系与具体的业务实体对象进行映射，并实现业务实体对象的数据访问。

3．数据库联接的设置：

ORM系统是与数据库进行交互操作，和数据库的连接就成为最首要的话题。Snake.Net框架支持业务实体对一个或多个不同类型的数据库的访问支持，在框架内可以使用两种方法设置数据库连接：使用配置文件和运行时设置。

Snake.Net允许在一个系统中可以同时使用多个数据库配置。同时提供了对不同种类的数据库具有广乏的支持，几乎可以使用当前所有主流的数据库产品。

优势：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（就目前而言）无法面对一切考验。