很多初學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)怎麼快怎麼來不要侷限工具。