Entity Framework 依賴傳遞：為什麼 UI 層也必須引用 EntityFramework.SqlServer.dll？

根本原因：元數據與類型身份

.NET 編譯器在編譯 UI 層時，需要完整了解 Service 層公共 API 中涉及的所有類型，包括：

• 方法參數/返回值類型（如 DbContext、DbSet<T>、SqlProviderServices）。
• 基類/接口繼承鏈（Service 繼承的 DbContext 來自 EF 核心程序集）。
• 屬性/註解類型（如 [DbConfigurationType]）。

若 UI 層不引用 EntityFramework.SqlServer.dll，編譯器無法解析這些類型的完整元數據（PublicKeyToken、版本、泛型實例化），導致運行時 CLR 找不到程序集。

對比：為什麼「只引用接口」有時可行？

最佳實踐：分層架構中的依賴管理

1. 領域模型獨立程序集：POCO 實體類放在 Domain.dll，無 EF 依賴，UI、Service 共同引用。
2. Repository 接口定義在 Domain：IUserRepository 返回 User (POCO)。
3. EF 實現放在 Infrastructure：EfUserRepository : IUserRepository 內部用 DbContext，引用 EntityFramework.SqlServer。
4. UI 僅引用 Domain + Service 接口，完全隔離 EF 實現細節。

// 目錄結構
MyApp.Domain          // 純 C# 類，零第三方依賴
MyApp.Services        // 引用 Domain，定義接口
MyApp.Infrastructure  // 引用 Domain, EF, SqlServer，實現接口
MyApp.Web/UI          // 引用 Domain, Services，零 EF 依賴

補充：.NET Core / EF Core 時代的變化

• EF Core 設計為輕量、可擴展，Provider (SqlServer, PostgreSQL) 作為獨立 NuGet 包。
• 同樣原理：若 Service 返回 DbContext 或實體類帶有 EF Core 註解，UI 仍需引用 Provider 包。
• 推薦 Repository + DTO 模式徹底切斷 UI 對 EF 的編譯時依賴。

總結

「UI 層未用到 EF 方法」是表象，本質是 Service 公共 API 洩露了 EF 類型。通過領域模型隔離、接口導向編程、依賴倒置，可實現 UI 與 ORM 框架完全解耦，同時解決「運行時找不到程序集」問題。