关于ORM的浴室沉思

这是一个由EF群引发的随笔

平时在一个EF群摸鱼，日常问题可以归纳为以下几种：

这条sql用linq怎么写？

EF可以调用我写的存储过程么？

EF好慢啊一些复杂查询写起来好麻烦……

为什么会有这些问题？

因为EF是一个“ORM”。基本上这些问题都有一个共同点：将EF当作data mapping tool来使用，而不是ORM。

什么是ORM？

ORM是随着面向对象（OOP）而来的。很早的时候RDB一统天下，大家也习惯了面向数据的开发习惯（其实现在也是）。OOP出来后业界就发现了问题：RDB是基于数学理论的，而面向对象（OOP）是从软件工程的基本原则发展出来的，两套理论存在着阻抗，例如现在我们定义一个简单的博客对象：

    public class Blog
    {
        public Guid Id { get; set;}
        public string Title  { get; set;}
        public string Content { get; set;}
        public List<string> Tags { get; set;}
    }

在这个博客对象中有个字符串泛型集合的标签属性，如果要持久化在RDB中一般用两种方法：1、标签单独一张表，Blog表与Tag表一对多关系；2、直接将Tags序列化（新一代的RDB提供的Json功能，所以一般是Json序列化）保存到Blog表中，用DDD的概念来说就是一种值对象（Value object）。

我们可以看到，第一种做法如果是直接将表映射到entity，那么我们最终得到的Blog类型可能并不是根据业务设计出来的样子，也就是说业务对象为RDB持久化的技术而妥协设计了。第二种方法看起来不错，但已经属于newsql的范畴，和RDB无关。

因此我们要明确的概念是：ORM是为了解决阻抗失配的，没有解决阻抗失配的都不是ORM，包括dapper、Mybatis等等等等（所谓micro orm其实并不是ORM），后者更适合的叫法应该是DMT（data mapping tool），只提供了表和entity的映射或者表达式树的处理。在DotNet这块，真正的ORM只有EF和NH两者（天国的linq to sql也不算，因为其只提供了DB First）。

扩展阅读：阻抗失配不仅仅是上述问题那么简单，例如OOP三要素——封装、继承、多态，假如你的业务对象存在继关系，那么在RDB中该如何描述？EF中提供了TPH (Table Per Hierarchy，父子类在同一张表，EF自动添加Discriminator字段用于标识属于哪一类型)、TPT (Table per Type，父子类在不同的表，子类表只包含子类属性，通过相同的Id来关联父类表上相同的entity父类数据)以及TPC(Table Per Concrete Type，没用过，也没见人用过，父子类在不同的表，父类的属性在子类表中也会存在，估计是为了优化query)三种方式，大家可以找下资料，在这里不做展开。

如何优雅地使用ORM

正确地使用ORM第一个前提是，项目必须是OOP设计，解析业务后先进行业务对象的建模，然后再通过ORM持久化业务对象的状态。以EF为例，基本排除了DB First以及Model First的做法，因为后两者属于面向数据库设计，所以EF Core只保留Code First除了更为精简外，其实也更符合ORM的实践。

然而：

这没有解决搜索（query）问题啊。

在这里我们要了解另一个概念——CQS（命令查询分离）。

CQS最早提出于1988年Bertrand Meyer的《面向对象软件架构》，可以归纳为“原则上一个方法不应该对数据造成影响（增删改）的同时又返回数据”。以是否对数据造成影响我们可以将操作分成两类：

查询（Query）：返回数据，不修改数据，不会产生副作用。

命令（Command）：修改数据，不返回数据，遵守单一职责原则。

在具体落地的项目中，查询往往千变万化，复杂的查询甚至要多表链接（大于3）还要进行聚合处理。其实我们可以看到，这里的查询几乎可以当作是弱报表——而几乎所有的这些查询，都不是OOP的功能。

因此虽然可以实现复杂查询，但ORM并不适用于CQS中的查询（Query）端。更好的做法是将项目的功能分成命令和查询两块，然后只在命令端使用ORM，Query端怎么快怎么来——当然具体实现也可以两边都用EF，但C端要当作ORM用，Q端直接执行sql语句。

扩展阅读：CQS并不是死规矩，例如stack的pop操作，有返回结果的同时也会改变stack本身。CQS落实到实际项目中并不是真的将操作简单地分成两类，比较简单的分法是：页面展示的一般是Q端。一些专业的项目C端甚至可以只通过Id来获取业务对象，这有助于仓储层的服务化以及事件溯源（Event Sourcing）的实现，以及在分布式系统中处理幂等。

最终总结，正确的使用ORM并没有想象中那么简单也没有那么难，其实也就是两条经验之谈：

1、必须是OOP设计，先使用Code First建好业务模型后再考虑如何持久化。

2、不能为Query而妥协设计，如果真的出现相对复杂的查询，直接CQS，Q端可以使用Dapper甚至Ado.net实现。

到了最后聊聊一些题外话，现在已经有各种DDD框架，但用了DDD框架并不代表你的项目就是DDD。同时有些DDD框架的实现就有待商榷，例如ABP其仓储层的设计就存在问题，因为它持久化的并不是DO（Domain object）的状态而是PO，这导致ABP的项目更类似于DDD Lite，这个问题我们以后有时间再说。