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

I'm looking for some advices about the unit of work pattern.

时的提交工作单位多次调用，或只是一个时间和随后离开该对象的垃圾收集？

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

这是个好主意，工作中发挥的单位注入或者我应该问对象时执行一些工作，各地通过它在方法调用？

Is it a good idea to inject the unit of work play or should I pass it around in method call when asking objects to perform some work?

推荐答案

的实现工作模式的单位类型的实例通常需要控制其寿命的一个老板。类似方法提交，打开，关闭和处置是一个类型，应明确控制（或后面放置一个抽象如果合适的话）常强的信号。

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

许多DI框架，为您提供定义的上下文中的对象和它的依赖运行的可能性。这使您可以注入自己工作的单位，并在其所有的依赖注入同样的实例。这是一个非常有用的功能，但不是我会做在这个特殊的情况下，因为你的code的正确性变得依赖于你配置你的工作单位范围的方式。这使你的code很含蓄，难以遵循，并易折断。国际海事组织这样的功能在场景中的是消费者不关心的依赖性特别有用。因此，此功能对于性能优化非常有用的，实现缓存策略和这样的。

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.

我希望这有助于。