工作单元模式

我正在寻找有关工作单元模式的一些建议。

工作单元上的提交是多次调用还是仅调用一次，然后将对象留给垃圾回收？

注入工作单元 play 是一个好主意，还是在要求对象执行某些工作时我应该在方法调用中传递它？

实现工作单元模式的类型实例通常有一个需要控制其生命周期的所有者。方法如Commit, Open, Close, and Dispose通常是强烈的信号，表明应显式控制类型（或在适当的情况下放置在抽象后面）。

出于这个原因，最好not注入工作单元实例本身，但注入知道如何创建此类工作单元的类型：工厂。

在这种情况下，工作单元充当上下文，当其他对象需要在同一上下文中执行操作（例如保持操作原子性）时，您需要传递它。这可能看起来像这样：

public class MyCommand
{
    private readonly IUnitOfWorkFactory factory;

    public MyCommand(IUnitOfWorkFactory factory)
    {
        this.factory = factory;
    }

    public void Execute()
    {
        using (var context = this.factory.CreateNew())
        {
            this.DoSomeNiceThings(context);

            context.Commit();
        }
    }
}

许多 DI 框架为您提供了定义对象及其依赖项运行的上下文的可能性。这允许您注入工作单元本身并在其所有依赖项中注入相同的实例。这是一个非常有用的功能，但在这种特定情况下我不会这样做，因为代码的正确性取决于您配置工作单元范围的方式。这使得你的代码非常隐含，难以理解并且容易被破坏。 IMO 这样的功能在消费者不关心依赖性的情况下特别有用。因此，此功能对于性能优化、实施缓存策略等非常有用。

是对工作单元的提交 多次调用或仅调用一次 然后将物体留下 垃圾收集？

是否打电话Commit多次是一个有效的场景取决于您如何设计它。在我的生产应用程序中，我经常在事务中运行我的工作单元，这允许我向数据库提交操作（例如获取数据库生成的密钥），同时保持业务操作原子性。

我希望这有帮助。