Encapsulating EF Core Usage 課程心得

https://enterprisecraftsmanship.com/.../new-course-ef.../

這課程蠻不錯的，裡面介紹到蠻多重要的概念，這邊做個總整理，如果大家看完我的心得有興趣，建議自費上上看去支持作者。

心得總結：

Module One

• Abstraction vs Encapsulation：抽象化是強調重點刪除細節、封裝是確保使用者無腦使用API不會造成錯誤。
• Abstraction的使用時機：如果加上間階層沒有降低複雜度，就是過度設計。
• Abstraction Hierarchy：要降低複雜度需要使用Abstraction，Abstraction有不同的階層，higher order abstraction封裝middle order abstraction、middle order abstraction封裝lower order abstraction，abstraction之間的依賴關係只能從高到低。(跟clean code內的same level of abstraction, implementation pattern的symmetry有異曲同工之妙)

Module Two

• Encapsulate dbContext：透過custom dbContext class來封裝config設定，降低客戶端config錯誤的機率。
• API設計：好的API目標在於降低使用上可能的選擇 (reduce the surface of API)，讓客戶端出錯的機率降低。

Module Three

• Repository使用時機：當需要aggregate或複雜物件時，將多餘的mapping logic封裝，降低客戶端使用的複雜度。課程提到一個爭議點：如果沒什麼邏輯，直接使用DbContext也沒什麼不可，這會違反Clean Architecture當中的依賴原則、也跟DDD用Repository限制客戶端存取Aggregate內部的概念有所不同。
• Generic Repository vs Non-Generic Repository：作者建議一律使用Non-Generic Repository，原因是讓程式碼可讀性高好、有效限制aggregate的存取 (個人認為作者自己這點打臉上面的描述)。

Module Four

• 為什麼不要partially initialized entity：當aggregate造成效能問題時，很可能是boundary切太大，應該要重新思考boundary而不是partially initialized entity。
• 為什麼不要使用unit of work封裝dbContext：Abstraction要能夠降低複雜度，作者認為單純使用一個介面為了封裝一行程式碼會造成更多複雜度，但也會違反Clean Architecture當中的依賴原則，work不work要等實際使用後才知道。

Module Five

• 為什麼IQueryable, IEnumerable會導致leaky abstraction：IQueryable強迫使用者了解哪些Linq能被EF Core了解，哪些不行，造成leaky abstraction、IEnumerable強迫我們了解dbContext是否被dispose，造成leaky abstraction。作者建議回傳IReadOnlyList，能降低mutable的風險，也不會有leaky abstraction的問題。
• 遵守參數generic、回傳型態specific的原則：參數越是generic，客戶端越能透過多型傳入不同概念；回傳型態越是specific，客戶端越能簡單使用需要的功能，而不會需要casting成自身想要的介面，降低runtime error與leaky abstraction的機率。

雖然普遍在業界沒什麼人care這些問題，working is enough :)) 。

還是多刷點Leetcode比較實在 :((( 。