你要的是Entity Framework吗?

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

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

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

是先设计数据库后再设计模型?在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)怎么快怎么来不要侷限工具。