使用带有实体框架的存储库和单元工作模式正确处理？

Question

干杯！我对将工作单元与存储库一起使用有些疑问。特别是实体框架中的子上下文角色。 我搜索了很多关于这个主题的信息，但我发现的只是不同类型的使用模式，我很困惑，我无法理解主要思想。

1.我应该在哪里实现配置和保存？ - DbContext 的 Inheritance 类中是否正确实现 Disposable？ 之后在 Repository 和 Unit of Work 中实现还是仅在 Uni fo Work 中实现？

-将方法Save放在工作单元或存储库中的什么位置？

我的存储库将是通用的 我的代码在架构师风格和其他细节上是否正确？请指出我的想法是否错误。

    interface IRepository : IDisposable
    {
        void Create();
        void Delete();
        void Update();
        void Get();
        T getSomeByExpression()
        ...Some another costum operations
        ...should I remember about Save here? 
    }

    class Repository : IRepository
    {
        SomeContext context = new SomeContext();
        ...Using using(context = new SomeContext()){} in functions??
        ... 
        ....Disposing?
    }

    interface IUnitOfWork : IDisposable
    {
     ...Which methods I should realize?
    Commit()
    Save()
    ...Need some another methods like rollback, Attach() Add() or Dispose or something else?
    }
    class UnitOfWork
    {
     ...Collection of Repository

    }

在逻辑级别的工作单元之后使用？ 请帮助我理解这个主题。

我想知道，如何正确使用 Unit Of Work 和 Repository 模式，尤其是包括 DBContext。我还想知道在哪里使用像 Dispose 这样的操作。 哪些操作应该在 UnitOfWork 中常见，Save 等。 如何在存储库中处理上下文？

Answer 1

这是一个great article，关于使用 MVC 实现工作单元。

我通常会在业务交易完成后处置该单位。例如，如果操作是创建父级、一些子级并附加它们，我会在完成后立即处理。

添加了与上述相关的更多细节：

在重新阅读您的问题时，听起来您想要更多关于工作单元理论而不是实际实施的信息，我很抱歉。

这里有一篇更好的文章on MSDN与此相关，但我会为你总结。

根据 Martin Fowler 的说法，工作单元模式“维护一个列表 受业务事务影响的对象并协调 写出更改并解决并发问题。”

通常，我使用工作单元模式将所有相关的存储库整合在一起，以解决并发问题，同时仍然保持存储库分开。

使用工作单元模式的最佳方法之一是允许 不同的类和服务参与一个单一的逻辑 交易。这里的关键是你想要不同的类 和服务彼此不了解，同时能够 登记在一个事务中。

• “我应该在哪里实现处置和保存？”

我不确定我是否完全理解您的问题，但我想您是在问什么应该管理工作单元的生命周期？

这是另一个与此相关的SO post，但摘要是目前拥有该工作单元的任何人，它与您如何设置工作单元的范围有关。例如，它可以是业务命令，也可以是 MVC 操作。

• “在 DbContext 的 Inheritance 类中是否正确实现 Disposable？之后是在 Repository 和 Unit of Work 中实现还是仅在 Uni fo Work 中实现？”

您的意思是，您应该在哪里处理 DbContext？我认为它应该在工作单元中。如果您在单个工作单元中创建/处理多个上下文，也许您应该将它们分成 2 个不同的单元。

• 将方法 Save 放在工作单元或存储库中的什么位置？

您的工作单元是处理上下文和事务，并且应该包含防止重复更新的逻辑，因此您的保存功能应该由您的工作单元控制。