现如今
对象关系映射（ORM）框架
被大量的使用于企业级应用的开发
为什么要使用ORM？
ADO.NET操作数据库不好吗？
我们可以仔细想想
当我们使用ADO.NET操作数据库的时候
我们需要先获取连接字符串
接着根据连接字符串创建一个SqlConnection对象来打开与数据库的连接
紧接着还要创建SqlCommand对象来执行数据库命令
根据不同的命令还要创建相应的不同的对象来进行操作
比如SqlDataAdapter和DataSet等
另外这次操作完成之后
还要注意关闭数据库的连接通道，释放资源等问题
或许当我们操作ADO.NET习惯了之后并不觉得哪里麻烦
但是相信使用过ORM的同学在真正开发的时候很少在直接用ADO.NET来操作数据库了
真的真的有这么好用嘛？
骗你又没糖吃
举一个很简单的例子（可能不是很恰当，将就着吧...）
比如现在你想吃一道菜
需要经过自己去准备食材，点火拿锅炒菜等一系列的动作
但是现在给你提供了一个大厨
不不，大厨不好
给你一个可爱温柔，厨艺又好的漂亮老婆
这个可以有吧？
只要告诉老婆你想吃什么菜
漂亮老婆就会帮你做出来
而不需要你去经历做菜的过程
在这期间你还可以去做其他的事情（在此可*发挥想象力...）
同样是吃到想吃的菜
你是选择费些精力自己去做
还是让老婆做？
这不是废话嘛！
而且老婆做的菜肯定比你自己做的好吃！
人家是有练过的！
ORM框架就相当于是你的老婆
...
同样是如此，ORM老婆操作数据库的性能和效率往往是比自己写的数据库操作要好
这就是ORM老婆框架所做的事情
她将数据库中的表和程序中的类用一种映射关系关联起来
做到了对数据库层的屏蔽
在之前，程序员需要耗费大量的时间、精力去编写具体的数据库访问的SQL语句
还要十分小心其中大量重复的代码是否有疏漏，并不能集中精力于业务逻辑开发
但是老婆的出现帮助程序员解决了这些问题
留给程序员的不在是繁琐的数据库操作
而且他们相当熟悉的类和对象
这从一方面大大降低了代码量，也使程序员更加专注于业务逻辑的实现
正如我们所知
数据库表与表之间的关系有可能十分复杂
1对1、1对多、多对1、多对多、级联等
在操作数据库时，程序员必须小心谨慎的注意这些关系
而这往往是十分痛苦的过程
ORM框架通过程序中的类和数据库中的表
建立起了一种关系映射
程序员通过操作熟悉的类和对象即可实现对数据库的操作
ORM框架会自动帮我们维护这些复杂的关系
这就做到了对数据库层的屏蔽
使得程序员可以方便，快捷的进行数据库操作
至于之前说到的性能问题
这就不得不讲到ORM框架一个十分重要和牛逼的技术
延迟加载
ORM框架将根据具体数据库操作需要，会自动延迟向后台数据库发送SQL请求
从而大大降低与数据库的交互次数，提高数据库吞吐率提高运行效率
此外
ORM也可以根据实际情况，将数据库访问操作合成，尽量减少不必要的数据库操作请求
这个老婆是不是很贴心？
方方面面都给你想到了你还不要？
不管你要不要反正我是要了
用她又不用钱！是吧
接下来介绍一下EF
Entity Framework是微软以 ADO.NET 为基础所发展出来的对象关系对应解决方案
ORM框架的中的一种
（众多老婆中的一个）
在早期
人们在.NET平台下经常使用的ORM框架是NHibernate
这是一个Java平台的Hibernate移植过来的ORM框架
其强大的功能和性能深受程序员的喜爱
这可是正房夫人呀
早早的就虏获了众多程序员的心
但是现在人们的中心已经渐渐的转移到了二房
没错
就是EF
注意，她不是小三...
原因很简单
看过狗血电视剧的同学应该都知道
二房一般都是比正房夫人漂亮的！
不然人家大地主为毛要娶那么多个
不就是因为一个比一个漂亮
一个比一个好用嘛！（这里好像有点用词不当...）
EF就是一个比NHibernate漂亮，好用的老婆
因为她能和.NET平台完美的结合
而且提供可视化的关系对象映射模型
前面提到过
ORM框架根据程序的类和对象与数据库的表建立起了一种映射关系
这个映射关系通过xml文档保存在程序内部（比如配置文件）
在NHibernate中
程序员需要编写很繁杂的xml代码来实现这种映射关系
而这个过程同样也是十分痛苦的
常常因为一点点小的配置问题导致无法访问数据库
这就是正房夫人的不对了吧
你让本大人受罪
再娶一个气死你
而在EF中
提供了一种edmx文件
它本质上还是一个xml文档
但是它可以为程序员提供一个可视化的界面图形
人们可以通过简单的鼠标或者键盘操作来完成关系的映射
看吧，是不是比那个当正房的漂亮又好用多了
ORM和EF的简单介绍到此为止
与此同时本菜鸟的MVC之旅也拉开序幕
欲知后事如何，且听下回分解