c# - 为什么存储库模式在 Entity Framework 中被广泛使用，好像它很复杂？

Question

我正在创建一个演示项目，其中包含使用存储库模式和依赖项注入(inject)的 crud 操作。

这是我的结构:

方法 1(非常流行，被许多开发人员使用)

我的存储库界面:

public partial interface IRepository<T>
{
    void Insert(T entity);
}

我的服务层:

public partial interface IEmployeeService
{
    void InsertCategory(EmployeeMaster employeeMaster);
}

我的类将实现该接口(interface)(服务):

public partial class EmployeeService : IEmployeeService
{
    private readonly IRepository<EmployeeMaster> _employeeMasterRepository;

    public EmployeeService(IRepository<EmployeeMaster> employeeMasterRepository)
    {
         this._employeeMasterRepository = employeeMasterRepository;
    }

   public virtual void InsertCategory(EmployeeMaster employeeMaster)
   {
        _employeeMasterRepository.Insert(employeeMaster);
   } 

这是我的 Controller :

public class HomeController : Controller
{
        private readonly IEmployeeService  _employeeService;

        public HomeController(IEmployeeService employeeService)
        {
            this._employeeService = employeeService;
        }

以上是我从 Nop Commerce 项目 ( http://www.nopcommerce.com ) 遵循的结构，我认为现在大多数开发人员都只遵循这种结构，即存储库模式和依赖注入(inject)。

以前我像下面那样在我的应用程序中制作一个 Bal(业务访问层)项目，然后在 Bal 中制作类文件并像下面那样插入:

方法 2:

public class MyBal()
{
    public void Insert()
    {
        using (MyEntities context = new MyEntities ())
        {
            var result = context.MyTable.Add(_MyTable);
            context.SaveChanges();
            return result;
        }
}

然后像这样从我的 Mvc 应用程序中直接调用此方法:

[HttpPost]
public ActionResult Insert(Model M)
{
    MyBal bal = new MyBal ();
    bal.Insert();
}

那么为什么大多数开发人员继续创建如此复杂的存储库模式结构。谁能解释一下方法 1 和方法 2 之间的区别？？

方法 1 是否提高了性能，或者它仅与代码分离或更好的代码可维护性有关。

Answer 1

许多人在 Entity Framework 之上实现 Repository，它本身使用 Repository Pattern。这背后的推理有一些变化；关于这些是否有意义的决定是见仁见智的。

1. 这是 Microsoft 在其教程系列 Part 9 of 10 中演示的方式.由于 Microsoft 展示了这种模式，因此它被广泛接受为一种合理的做法。

2. 与 Entity Framework 分离。许多人努力将 Entity Framework 从他们的业务实体中分离出来，他们的想法是如果他们选择替换 Entity Framework，他们可以在不修改其他业务逻辑的情况下更改存储库。然而，在实践中，您应该真正致力于一项技术，正确分离 Entity Framework 逻辑需要大量工作。最后，您很可能最终会在存储库中使用仅因为它是 EF 做事方式而存在的方法，因此更改为另一个 ORM 仍会影响您的业务实体。

3. 泛型。将泛型与存储库模式结合使用是一种非常常见的做法，它可以最大限度地减少代码重复。这个想法是，如果您有数百个类来执行 CRUD 操作，那么通用存储库将更加统一且更易于维护，但灵 active 可能会降低一些。

4. 易于与依赖注入(inject)工具集成。在某些情况下，使用存储库模式可能更容易使用依赖注入(inject)工具。

5. 单元测试。这与第 4 点一致，使用存储库模式为您提供了一个统一的类，可以轻松模拟单元测试。

这绝不是一个详尽的列表，不同意每个观点的理由与同意它们的理由一样多，但这是我对围绕这一特定模式的思维过程的观察。

关于您的第二个问题，两个示例之间的区别...在第一种情况下，您创建了一个服务和一个存储库，它们可能存在于完全不同的项目或命名空间中您的企业实体。您的业​​务实体不知道或不关心 Entity Framework 。如果您需要更改 Repository 的工作方式，它对您的实体应该几乎没有影响，它会像往常一样运作。

在第二种情况下，您直接绑定(bind)到 Entity Framework 。这个和任何其他业务实体必须了解 Entity Framework ，对 Entity Framework 的任何更改都可能意味着更改此实体或任何其他类似实体中的代码。对于许多实体，这可能是一个非常漫长的过程。此外，您无法轻松测试此实体，因为您执行的任何测试都会导致写入数据库。