iT邦幫忙

0

你要的是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)怎麼快怎麼來不要侷限工具。


尚未有邦友留言

立即登入留言