工作单元模式

发布于 2024-10-16 17:23:17 字数 123 浏览 2 评论 0原文

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

白云悠悠 2024-10-23 17:23:17

实现工作单元模式的类型实例通常有一个需要控制其生命周期的所有者。 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 是否是有效的场景取决于您的设计方式。在我的生产应用程序中，我经常在事务中运行我的工作单元，这允许我向数据库提交操作（例如获取数据库生成的密钥），同时保持业务操作原子性。

我希望这有帮助。

Instances of types that implement the unit of work pattern usually have a single owner that needs to control its lifetime. Methods like Commit, Open, Close, and Dispose are often strong signals that a type should be controlled explicitly (or placed behind an abstraction if appropriate).

For this reason it is better not to inject an unit of work instance itself, but inject a type that knows how to create such unit of work: a factory.

The unit of work in that case functions as a context and when other objects need to perform operations in the same context (to keep the operation atomic for instance) you need to pass it. This might look like this:

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

Many DI frameworks offer you the possibility of defining a context in which an object and its dependencies run. This allows you to inject the unit of work itself and inject that same instance in all its dependencies. This is a very useful feature, but not something I would do in this particular scenario, because the correctness of your code gets dependant on the way you configure the scope of your unit of work. This makes your code very implicit, hard to follow and easy to break. IMO such feature is especially useful in scenario's were the consumer doesn't care about the dependency. This feature is therefore very useful for performance optimizations, implementing caching strategies and such.

Is the commit on the unit of work
called multiple times or just one time
and then leaving the object for
garbage collection?

Whether calling Commit multiple times is a valid scenario depends on how you design it. In my production applications, I often run my unit of work inside a transaction, which allows me to commit operations to the database (to get database generated keys for instance) while keeping the business operation atomic.

I hope this helps.

回复收藏 0 原文