你要的是Entity Framework吗?

很多初学Entity Framework( Core)(以下简称EF)的新手，刚开始使用EF时都会有一个感觉，这个工具很方便不需要写一堆SQL去存取资料库，很容易的就把资料转换成物件让程序很容易操作。
然後过了一段时间後就会开始产生一堆困扰，譬如:

• 为什麽一定要设计物件，EF才能使用?
• 为什麽LINQ JOIN语法那麽复杂?
• 为什麽EF产出的SQL语法效能那麽差?

而这些问题的主因在於大多数人并没有用对(或是明白)EF是ORM这件事情，这篇文章不解释ORM的目的，那麽对於新手怎麽确认是否用对EF了?
有两种方式可以判断

1. 是先设计数据库後再设计模型?
2. 在EF中使用LINQ是否有使用到JOIN语法?

如果上述两项任何一项的答案为是，那麽其实是用错EF了。
或许有人认为这种说法很极端，EF只是个工具只要好用就行，然而我目前遇到的大多数询问的EF问题，其实并不是问题，而是不正确的使用EF。
其实绝大多数要的并不是EF而是数据映射工作(Data Mapping Tool)(以下简称DMT)。
严格说起来目前在.Net中只有两样产品能称为ORM，Entity Framework与NHibernate(以下简称NH)，其他称之为ORM或是Micro ORM的产品绝大部分都是DMT，因为这些产品都没办法达到基本的ORM功能如封装与继承的映射。
DMT与ORM在本质上最大的不同在於DMT是以数据先行来设计，而ORM是以物件(模型)先行，也就是上面的第一点判断方式。
自然的既然ORM是物件先行方式，当然就不会有JOIN这种概念，物件与物件之间是聚合、引用等关系存在，因此使用ORM时就不应该使用到JOIN语法。
这也是为什麽EF在4.1之後加入了Code First设计模式，EF Core之後不支援EDMX的主要原因。
EF在设计之初的野心很大，原本的目的是要创造一个让微软所有技术存取数据的一项标准，但却又用ORM的名义推出，所以很多特性其实是违反ORM原则的，当初在MSDN论坛上被很多人诟病而慢慢往纯ORM的方向发展，直到EF Core重新设计以完完全全是基於ORM的特性来设计。
如果要熟悉了解ORM的原理与设计，可以看下这本 Martin Fowler大师的名着 "企业架构设计" ，EF与NH基本上都是完全按这本书中的原理来设计的。
所以如果在设计的方式并不是采用物件(模型)先行方式设计，那麽可能EF并不是真正你想要的工具，而是ibatis、Dapper这类DMT工作才是你应该使用的。
当然这不代表不能使用EF，但遇到问题时应该仔细想想这个问题是不是违反了ORM的目的，透过其他办法来处理，而非是抱怨EF难用或是说EF怎麽没这些功能。

最後补充一点，也是最多人询问的问题-EF如何做复杂查询。其实这个问题微软官方已有说明，EF并不适合做为复杂查询(原因同上，EF是ORM)，那麽该如何解决复杂查询的问题呢?答案其实很简单，使用CQS(
Command–query separation)模式来设计，命令端(Command)使用EF，查询端(Query)怎麽快怎麽来不要局限工具。