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

2年前 (2022) 程序员胖胖胖虎阿

502 0 0

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语句。