4

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

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

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

4

2 回答 2

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();
        }
    }
}

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

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

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

我希望这有帮助。

于 2011-02-09T11:24:15.903 回答
0

工作单元背后的想法是封装一个“工作单元”，例如从单个方法中的操作强制执行的所有更改（例如，添加具有某些角色的用户，将添加用户以及与用户关联的角色） .

您将使用一个工作单元来“批量”这些更改并一次性执行它们（通常通过事务 - 因为不同的操作构成一个工作单元，如果一个失败 - 都应该）

所以真的，每个工作单元你只会调用一次提交。大多数 ORM/s 像实体框架/休眠允许您通过单个工作单元执行多个提交，每个提交都与代表一个工作单元的特定事务相关联。

于 2012-07-06T21:54:57.977 回答