使用 UnitOfWork 时适当分离关注点？答案

【问题标题】：Proper Separation of Concerns When Using UnitOfWork?使用 UnitOfWork 时适当分离关注点？
【发布时间】：2019-11-25 16:28:03
【问题描述】：

我使用了实体框架的 UnitOfWork 模式在线教程，因为我已经有一段时间没有使用它了。我很困惑为什么在教程中 DataContext 是公共 UnitOfWork 构造函数的参数。这意味着如果我在应用程序的另一层使用 UnitOfWork，另一层必须知道 DataContext。这似乎不是一个很好的关注点分离。我错过了什么吗？

工作单元：

 public class UnitOfWork : IUnitOfWork
    {
        private readonly PurchasingDataContext _context;

        public UnitOfWork(PurchasingDataContext context)
        {
            _context = context;
            Items = new ItemRepository(_context);
            Manufacturers = new LabelerRepository(_context);
            Quotes = new QuoteRepository(_context);
            Vendors = new VendorRepository(_context);
            Contacts = new ContactRepository(_context);
        }



        public IItemRepository Items { get; private set; }
        public ILabelerRepository Manufacturers { get; private set; }
        public IQuoteRepository Quotes { get; private set; }
        public IVendorRepository Vendors { get; private set; }
        public IContactRepository Contacts { get; private set; }

        public int Complete()
        {
            return _context.SaveChanges();
        }

        public void Dispose()
        {
            _context.Dispose();
        }
    }

界面：

public interface IUnitOfWork : IDisposable
    {
        IContactRepository Contacts { get; }
        IItemRepository Items { get; }
        ILabelerRepository Manufacturers { get; }
        IQuoteRepository Quotes { get; }
        IVendorRepository Vendors { get; }
        int Complete();
    }

【问题讨论】：

“我错过了什么吗？” - 依赖注入。

标签： c# entity-framework design-patterns unit-of-work

【解决方案1】：

我很困惑为什么在教程中 DataContext 是 public UnitOfWork 构造函数的参数。

这是为了使将依赖项注入 UoW 成为可能。通过这样做，您可以轻松地兑现SRP。
有了它，您可以在 UoW 之外单独管理DataContext 的范围。这为您在不同场景（例如 Windows 应用程序与 Web 应用程序）中使用相同的 UoW 提供了很大的灵活性。有了这个，你可以按照你想要的方式扩展数据库事务。

这意味着如果我在应用程序的另一层使用UnitOfWork，另一层必须知道DataContext。

是的；但不完全正确。是的，DataContext 的实例应该通过调用 layer.管理（创建、注入和处置）。就是这样。该层不需要以任何方式与此实例交互。

这似乎不是一个很好的关注点分离。

继续前面的观点，调用层不需要知道该实例是如何工作的。所有这部分都在你的 UoW 类中抽象出来。这是关注点的清晰分离。

我错过了什么吗？

希望你现在知道。

【讨论】：

【解决方案2】：

我首先要问您为什么要在 UnitOfWork 中创建和公开这些存储库。拥有一个负责一个工作单元的类和所有存储库的所有权违反了单一职责原则。您的 IUnitOfWork 公开调用者可能需要或不需要的每个存储库违反了接口隔离原则。

您应该使用依赖注入框架来管理上下文、存储库和工作单元的生命周期，而不是这种方法。该框架应确保为每个请求创建一个实例，并在需要时跨依赖项共享。

一个典型的 EntityFramework UnitOfWork 看起来类似于：

public interface IUnitOfWork
{
    void SaveChanges();
}

实现如下：

public class UnitOfWork : IUnitOfWork
{
    private readonly PurchasingDataContext _context;

    public UnitOfWork(PurchasingDataContext context)
    {
        _context = context;
    }

    public void SaveChanges()
    {
        return _context.SaveChanges();
    }
}

【讨论】：