ORM数据层框架的设计热点：更新指定的列的几种设计方案

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();
} 

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

 

C# Aop简单扫盲及ORM实体类属性拦截示例

 

Aop RealProxy 千年遇BUG

 

 

贫血模式的示例：

    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万房子~~