如何在此模式中将 EF POCO 与通用 IRepositary 分离？

Question

我当前的Repository/UnitOfWork模式已关闭。然而，有一个硬耦合，我无法弄清楚如何摆脱。

这是我的模式概述：

业务逻辑层

• I存放＜ul＞
• 用作类型约束

• 实现独立性
• 一般 CRUD 方法

• 实现IReposory

• 存储库的Getter
• Save方法

• 强制（并公开）DTO和EF POCO的接口具有名为ID的Int32字段
• 用作类型限制

• 核心项目和（即将到来的）测试项目中使用的DTO实体

数据层（注入Ninject）

• 工作单元
  • 基于实体框架的 IUnitOfWork 的实现
  • I员工存储库的实现
  • EF POCO

  果心

  • 员工控制员＜ul＞
  • 参数化构造函数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*的员工结果列表）。所以这不是一个好的选择。

  另一个更可行但不是最优的解决方案是使用动态LINQ。这样，我可以在Find/FindAll方法中传递一个简单的字符串，并消除TModel需求。然而，这意味着重构变得令人讨厌，因为它用魔法字符串填充代码。

Answer 1

另一种方法是使数据层依赖于业务层，并将存储库“项目”实体映射到业务对象（DTO）中。这样，BL位于底部，UI和数据依赖于它，但UI和数据互不依赖。

这是马克·塞曼在他的《依赖注入》一书中支持的方法。

Answer 2

就在我发布这个的时候，我想我找到了我的问题所在。

Find()和FindAll()甚至不应该存在。我应该在IEmployeeRepository中编写更具体的方法，如FindEmployeeByName(字符串名称),然后像这样实现它:

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

有人能证实这是正确的方法吗？或者建议更好的东西？

编辑

还有，如果我想继续找(表情...)和FindAll(表达式...)方法，我可以，但它们只是在数据层，被实现的方法使用，以避免重复代码。但是它们不应该在控制器中使用，因为它们需要底层数据结构的知识，超出了我的业务逻辑。也就是说，它们可以在BaseRepository中实现

不知道我是否正确解释了这一点。如果不清楚，请告诉我，我会尝试编辑它并使其更好。