工作单元模式

Kar*_*ten 4 .net design-patterns dependency-injection unit-of-work

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

工作单元上的提交是多次调用还是只调用一次,然后将对象保留为垃圾回收?

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

Ste*_*ven 5

实现工作单元模式的类型实例通常只有一个需要控制其生命周期的所有者.像的方法Commit,Open,Close,和Dispose是一个类型应明确控制(或如果合适的话放置一个抽象的后面)常强的信号.

出于这个原因,最好不要注入一个工作单元本身,而是注入一个知道如何创建这样一个工作单元的类型:工厂.

在这种情况下,工作单元作为上下文,当其他对象需要在同一个上下文中执行操作时(例如,保持操作原子),您需要传递它.这可能如下所示:

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();
        }
    }
}
Run Code Online (Sandbox Code Playgroud)

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

工作单元上的提交是多次调用还是只调用一次,然后将对象保留为垃圾回收?

是否Commit多次调用是有效的方案取决于您的设计方式.在我的生产应用程序中,我经常在一个事务中运行我的工作单元,这允许我将操作提交到数据库(例如,获取数据库生成的密钥),同时保持业务操作的原子性.

我希望这有帮助.