ORM框架的定义：对象-关系映射（Object/Relation Mapping，简称ORM）

常见的是：数据库结构=》映射Object（实体属性）=》基于实体类的操作。

还有一种：数据库结构=》映射Object（内存表结构）=》基于内存表的操作。

当然，如果你有创意，你还能创造出更多的映射载体来实现ORM。

避免思维定式：

由于思维定式，很多开发者，只有见到基于实体类映射，才会认为是一种ORM框架，于是很少人去思考其它映射载体来实现ORM。

这个思维定式，和早期在ASP.NET MVC没出来之前，把WebForm框架当成ASP.NET一样，于是很少人会去创造另一种开发框架。

不过要避免思维定式，有时候的确不是件容易的事~~~这需要太多知识的沉淀和积累，这个就先不扯了，下面来正题。

ORM生成SQL：

一般的数据库下，都是基于SQL语句解析执行的，所以ORM最终都避不开生成SQL再交还ADO.NET去执行，从而返回结果。

由于ORM存在映射关系，最简单的是（字段名称+数据类型）的实体映射，因此，通常只要遍历实体的属性就可以拿到所有字段名称，从而组合SQL去执行了。

而反射的应用，对于实体型映射的ORM无疑是佳方案，节省大量代码；通过反射，在处理时动态获得指定对象的类型、字段名称、字段类型、或者特性描述等信息，从而构造出SQL语句。

如果是基于内存表（MDataTable）映射的，则无需反射，因为映射的时候，相关结构已提前预约好了，直接遍历获取即可。

ORM的两种实体型实现方式：充血和贫血

这里先不说基于内存表的映射，说说基于实体映射的设计方案：

充血模式的示例：

public
class Users : CYQ.Data.Orm.OrmBase 
     { 
public Users() 
         { 
base.SetInit( 
this); 
         } 
public
int ID {  
get;  
set; } 
public
string UserName {  
get;  
set; } 
public DateTime CreateTime {  
get;  
set; } 
     } 

这种方式，增删改查，都由基类处理了，而基类一般需要三个参数：

1：子类的对象，用于反射类型及属性的需要。 
2：表名（可选，如果不写，则从反射中拿到类名当表名） 
3：数据库链接（可选，如果不写，则会默认约定一个配置名称的数据库链接） 

最终的操作方式类似：

using (Users u =  
new Users()) 
             { 
                 u.UserName =  
"
u1
"; 
                 u.Update(1); 
             ｝ 

如果按常规，我们可能会循环所有字段，全部更新；很明显在这里我们只需要更新UserName。

于是，在设计上，我们需要额外多出一个集合，来存储字段对应的状态，这个集合怎么设计，这个大伙自行发挥了。

这里的难点，在于，如何设计获取状态改变上。

充血模式的两种更新指定列的设计方案：

1：把动作交给实体，这种方案比较常规，动动脑就想的出来：

直接切入实体的Set属性，如：

public
string UserName 
         { 
get; 
set
             { 
base.SetState(value); 
             } 
         } 

然后事情就交给基类的SetState方法去修正对应实体的状态，遍历属性的时候，再比较状态，取得只需要更新的字段去组合即可。

2：把动作交给基类：利用AOP动态拦截属性，这种方案实现相对复杂

这种方案，优点是：可以保持实体类的相对简洁，通过在基类利用AOP拦截子类的Set方法，从而动态的调用SetState方法。

缺点是：实现有点难度，另外是由于AOP基类ContextBoundObject的限制，内部无法使用泛型。

即你不能实现：Select<T>()类似的方法，所以最终的表达式可能需要借第三个类的ToList()方法来返回，代码类似：

using(Users u =  
new Users()) 
 {  
      List<Users> list= u.Select().ToList(); 
 }  

具体的方案实现可以见我以前写的这两篇文章：

贫血模式的示例：

public
class Users  
     { 
public
int ID {  
get;  
set; } 
public
string UserName {  
get;  
set; } 
public DateTime CreateTime {  
get;  
set; } 
     ｝ 

这种方式，实体就类似数据载体，本身不具备增删改查功能，类似把基类独立开来操作。

最终的调用方式可能类似：

 Users user= DBFast.Find<Users>( 
1); 
//
查询记录。
 Users u= 
new Users(); 
 u.UserName= 
"
u1
"; 
DBFast.Update<Users>(u,
1
);
//
更新。

贫血模式的两种更新指定列的设计方案：

对于贫血模式，也有两种对应的设计方案：

1：实体还是原生态的：

public
class Users  
     { 
public
int ID {  
get;  
set; } 
public
string UserName {  
get;  
set; } 
public DateTime CreateTime {  
get;  
set; } 
     ｝ 

由于没有基类，所以状态的变化，无法很好的集成的，因此，这种情况的设计，通常需要多一行额外的代码来传递信息。

例如：

 Users u= 
new Users(); 
 u.UserName= 
"
u1
"; 
 DBFast.SetState<Users>( 
"
UserName
",State 
.ForUpdate);//类似的多了一行来指定需要更新的一个或多个列的状态。 
 DBFast.Update<Users>(u, 
1); 
//
更新。

2：可以Nullable的实体：

public
class Users  
     { 
public
int? ID {  
get;  
set; } 
public
string UserName {  
get;  
set; } 
public DateTime? CreateTime {  
get;  
set; } 
     ｝ 

对于这种模式，可以让值类型的默认值也为Null，因此可以通过减免值为Null的列，来实现更新值不为Null的值。

不过对于这种方式，由于DBNull.Value只能给引用类型赋值，因此值类型的字段无法重置为Null。

所以，如果要实现对值类型赋Null值，可能需要增加一行代码来对指定的行指定状态，配合着使用；或者直接操作SQL语句。

总结回忆：

记得前些日子和腾讯的架构师面试的时候，好像也交流到了这个指定列的更新的话题上，不过那时候的话题，上升到分布式话题了：

问题：大体是有一份数据载体情况下，用户更新了某些字段，如何只更新某些字段的话题：

1：先是说前端的过滤与传递只需要更新的数据（对方：这个先假设没有做）。

2：服务端可以做缓存，然后比较（对方：假设服务器有很多，做了负载，如何保证）。

3：全局共享缓存或用分布式缓存（对方：假设没有分布式缓存，只有Web服务器缓存，只有一份副本）

4：通过某种算法，让用户的请求的数据对应到相对的副本的服务器。（对方：算法怎么实现）

5：。。。此处省略600字了。。。

不知不觉又写了好几个小时了，今天就介绍到这里了~~~谢谢大伙~~~~

最后给贴一下今天各大群热传的励志文：月领1万2小IT职员五年在北京买500万房子~~