如何以這種模式將EF POCO與通用IRepository分離？

Question

我目前有一個Repository / UnitOfWork模式。 但是，有一種硬耦合無法解決。

---

這是我的模式的概述：

業務邏輯層

• 知識庫
  • 用作約束
• IRepository <TModel，TDTO>
  • 實現IRepository
  • 通用CRUD方法
• IEmployeeRepository <TModel>
  • 實現IRepository <TModel，EmployeeDTO>
  • 一些員工特定的方法
• IUnitOfWork
  • 儲存器的吸氣劑
  • 保存方式
• IEntityWithId
  • 強制（和公開）DTO和EF POCO具有稱為ID的Int32字段的接口
  • 用作類型約束
• EmployeeDTO（與已實現的EmployeeRepository中的AutoMapper映射）
  • 核心項目和（即將）測試項目中使用的DTO實體

數據層（使用Ninject注入）

• 工作單位
  • 基於實體框架的IUnitOfWork的實現
• 員工資料庫
  • IEmployeeRepository <TModel>的實現
• 雇員
  • EF POCO

核心

• 員工控制器
  • 參數化構造函數EmployeesController（IUnitOfWork unitOfWork）
  • IUnitOfWork與Ninject模塊一起作為UnitOfWork注入（來自數據層）

---

這些是我的通用IRepository接口中的問題方法。

TDTO Find(Expression<Func<TModel, bool>> filter);

和

IEnumerable<TDTO> FindAll(Expression<Func<TModel, bool>> filter);

---

如您所見，其中有TModel，用於構建表達式以過濾結果。 我可以做一些類似於在DTO上使用表達式的操作，但是這需要映射到DTO的雇員的完整列表（也就是不會生成SQL過濾器，但是會過濾SELECT * FROM Employee結果列表）。 因此，這不是一個好選擇。

另一種更可行但並非最佳的解決方案是使用動態LINQ。 這樣，我可以在Find / FindAll方法中傳遞一個簡單的字符串，並擺脫TModel的要求。 但是，這將意味着重構變得很煩人，因為它用魔術字符串填充了代碼。

Answer 1

正如我發布此文章一樣，我想我已經弄清楚了問題所在。

Find（）和FindAll（）甚至都不存在。 我應該在IEmployeeRepository中編寫更具體的方法，例如FindEmployeeByName（string name），然后像這樣實現它：

EmployeeDTO FindEmployeeByName(string name)
{
    return Mapper.Map<EmployeeDTO>(dbSet.Where(o=>o.name.Contains(name)).FirstOfDefault());
}

誰能確認這是正確的方法？ 或提出更好的建議？

編輯

另外，如果我想保留Find（Expression ...）和FindAll（Expression ...）方法，可以，但是它們只是在Data層中，已實現的方法使用它們來避免重復代碼。 但是，不應將它們用於控制器中，因為它們需要了解除我的業務邏輯之外的底層數據結構。 就是說，可以在BaseRepository <TModel>中實現它們（我已經提過，但沒有提到使事情更簡單），並使EmployeesRepository擴展了BaseRepository。 這樣，每個存儲庫都已經具有可識別模型的類通用方法。

不知道我是否解釋正確。 如果尚不清楚，請告訴我，我將嘗試對其進行修改並使其變得更好。

Answer 2

執行此操作的另一種方法是使數據層依賴於業務層，並使存儲庫“項目”實體進入業務對象（DTO）。 這樣，您的BL位於底部，UI和Data相互依賴，但UI和Data不相互依賴。

這是Mark Seemann在其關於“依賴注入”的書中所擁護的方法。