导读：跳进了多租户切换数据库的坑，那么就继续走下去吧。在我们的项目中，是运用EF实现对数据库的操作，那么EF其实是.NET系统中，基于ORM框架的一个产品实现。在java那边，则有Hibernate和ibatis等具体实现。既然研究的是ORM的具体实现，那么还是很有必要介绍一下ORM的原理的。因为本人主要是基于EF研究，所以在描述过程中，均已EF开发作为实例。
一、ORM
1.1，概念
对象关系映射（英语：Object Relational Mapping，简称ORM，或O/RM，或O/R mapping），是一种程序技术，用于实现面向对象编程语言里不同类型系统的数据之间的转换。从效果上说，它其实是创建了一个可在编程语言里使用的“虚拟对象数据库”。
1.2，概念理解
O（Object）
它是程序设计中的对象，具体说来，也就是在开发过程中，所建立的Model层，在Model层中，每一个类都描述了一个对象，比如说：
<span style="font-family:KaiTi_GB2312;font-size:18px;">using System;
using System.Collections.Generic;
namespace MyModel.Models
{
public partial class TestTableone
{
public string Id { get; set; }
public string name { get; set; }
public string sex { get; set; }
public string testcolumn { get; set; }
}
}
</span>上面的这个类，其实是描述了一个对象：TestTableone
R（Relational ）
它是程序设计中的关系数据库（ORM框架，一般来说对应的是关系型数据库），具体说来，它其实是描述作为咱们数据持久层里面的表单。也就是说，它实际上是指咱们设计好的数据库对象，每张表单的字段、主外键、索引等。
M（Mapping）
比起映射，或者说直接理解为地图，更能让我们接受。想象地图在我们生活中是用来干嘛的？它能帮助我们找到目的地。那么，在程序中，mapping文件是用来干嘛的呢？这就涉及到ORM框架的工作原理，我们将在第二部分进行介绍。
图像理解：
二、EF工作原理
ORM框架最基本的工作原理，其实就是通过操作O（对象）去实现操作R（表单），而他们之间的连接或者说桥梁，就是Mapping（映射）。
下面，主要介绍一下产品EF的工作原理：
2.1，EF框架示意图
2.2，原理分析
首先，基于最底层的是SSDL，与之对应的是ADO.net的存储模型（数据库服务器）驱动。这里进行了数据库服务驱动，以及数据库的描述。
然后，基于中间层的是CSDL，与之对应的是EntityClient的实体数据驱动，在这里确定了ORM框架中的驱动形式，EF中使用EF驱动，ORM其他产品，都有自己对应的驱动。在这里面，是对于EF中的实体对象进行了描述。
最后，基于最上层的是对象元数据和对象服务，包含了对于对象的一系列操作。
那么，EF工作的时候，它通过最上层的对象服务，去操作对象元数据，而后过渡到EF的数据驱动，将最上层的操作，通过CSDL规则文件进行描述。然后紧接着，借助MSL映射规范，将CSDL描述的的内容，对应到SSDL（数据库表单），最后通过ADO.net的数据驱动，将SSDL描述的内容读写到具体的数据库。到最后进行读写操作的，一定会是数据库服务驱动所要求的语言，这一个过程，也是使用linq toSQL的一个具体流程。
三、EF的优缺点
3.1，优点
隐藏了数据访问细节，“封闭”的通用数据库交互，这是ORM的核心。它使得我们的通用数据库交互变得简单易行，并且完全不用考虑该死的SQL语句。
ORM使我们构造固化数据结构变得简单易行，不用将模型操作转化为一条一条的SQL语句。
3.2，缺点
EF牺牲了性能，虽然在于SQL语句转化的时候，耗费的时间非常小，但是它仍然远远没有直接执行SQL语句速度快。
对于一种复杂的查询，EF显得力不从心。最为显著的一个就是，多表联合查询。
四、总结
先来看下面一段话：
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.
作为一个优秀的开发人员，已经厌倦了这种重复的工具（重复的编写SQL语句），他们有一种典型的倾向，一种高效的懒惰开始显示出来：去创造一种工具，帮助实现自动化过程。当和关系型数据库打交道时，这种高明懒惰的努力成果是：ORM框架。
ORM框架到底是一种Helper，帮助我们实现了操作数据库语句的封装，它在本质上就等同于我们之前所写过的SQLHelper，当它的封装，满足不了自己的开发时，我们就开始抱怨。当它的封装可以满足时，我们就开始窃喜。可是，ORM对于自己的定位，从来都不是一种全能全效的产品，它只是一种工具。结合到目前的项目来看，我们想要依靠EF去实现多租户的数据库切换，我们在抱怨它能实现的模式，有弊端。没弊端的模式，实现不了，或者是困难重重。但是，这都是我们自己的要求太高了，框架本身就是一种平衡。有所舍弃，才有所获得。又想好又想巧，买个老驴不吃草，这都是不现实的。
下面会陆续总结在项目中所遇到的困难和分析，目前我们的实现有很多的问题，如有高人到此，请不吝赐教。