让我们从呼应伊恩开始：在DbContext@H_419_6@整个应用程序中只有一个是一个坏主意。唯一有意义的情况是当您拥有单线程应用程序和该单个应用程序实例专用的数据库时。这DbContext@H_419_6@不是线程安全的，并且由于DbContext@H_419_6@缓存数据，因此很快就会过时。当多个用户/应用程序同时在该数据库上工作时，这将给您带来各种麻烦（这是很常见的）。但是我希望您已经知道这一点，并且只想知道为什么不将它的一个新实例（即具有短暂生活方式）DbContext@H_419_6@注入需要的任何人。（有关为何单个DbContext@H_419_6@线程（甚至每个线程的上下文）不好的更多信息，请阅读此答案）。
首先让我说，将DbContext@H_419_6@临时工作注册为可行，但是通常您希望在一定范围内拥有一个这样的工作单元的单个实例。在Web应用程序中，在Web请求的边界上定义这样的范围可能是实用的。因此，按网络请求的生活方式。这使您可以让整套对象在同一上下文中操作。换句话说，它们在同一业务交易中运作。
如果您没有目标要在同一上下文中进行一组操作，那么在这种情况下，短暂的生活方式就可以了，但是需要注意以下几点：
另一种选择是 根本不 注入aDbContext@H_419_6@。相反，您注入了一个DbContextFactory@H_419_6@能够创建新实例的（我过去曾经使用这种方法）。这样，业务逻辑即可明确控制上下文。如果可能看起来像这样：
public void SomeOperation()
{
using (var context = this.contextFactory.CreateNew())
{
var entities = this.otherDependency.Operate(
context, "some value");
context.Entities.InsertOnSubmit(entities);
context.SaveChanges();
}
}
@H_419_6@好的一面是，您可以DbContext@H_419_6@显式管理显式表的生命，并且很容易进行设置。它还允许您在一定范围内使用单个上下文，这具有明显的优势，例如在单个业务事务中运行代码，并且能够传递实体，因为它们源自同一实体DbContext@H_419_6@。
缺点是您将必须在DbContext@H_419_6@from方法与方法之间进行传递（这称为“方法注入”）。请注意，从某种意义上说，此解决方案与“作用域”方法相同，但是现在范围是在应用程序代码本身中控制的（并且可能会重复很多次）。负责创建和处理工作单元的是应用程序。由于DbContext@H_419_6@是在构造依赖关系图之后创建的，因此构造器注入不在画面之内，并且当您需要将上下文从一个类传递到另一类时，您需要遵循方法注入。
方法注入并没有那么糟糕，但是当业务逻辑变得更加复杂，并且涉及到更多的类时，您将不得不将其从方法传递到方法，并将类传递给类，这会使代码复杂化很多（我已经看到了）过去）。对于简单的应用程序，这种方法虽然可以。
由于不利因素，这种工厂方法适用于较大的系统，另一种方法可能有用，那就是让容器或基础结构代码/组合根管理工作单元的方法。这是您的问题涉及的样式。
通过让容器和/或基础结构处理此问题，您的应用程序代码不会因必须创建，（可选）提交和处置UoW实例而受到污染，这使业务逻辑变得简单明了（仅是单一职责）。这种方法存在一些困难。例如，您是否提交并处置该实例？
可以在Web请求结束时完成工作单元的布置。但是，许多人 错误地 认为这也是提交工作单元的地方。但是，在应用程序中的那一点上，您根本无法确定应确实落实工作单元。例如，如果业务层的代码抛出异常是被提到的调用堆栈越高，你肯定 希望提交。
真正的解决方案是再次明确管理某种范围，但是这次在“合成根”内部执行。在命令/处理程序模式之后抽象所有业务逻辑，您将能够编写一个装饰器，该装饰器可以包装在允许执行此操作的每个命令处理器周围。例：
class TransactionalCommandHandlerDecorator<TCommand>
: ICommandHandler<TCommand>
{
readonly DbContext context;
readonly ICommandHandler<TCommand> decorated;
public TransactionCommandHandlerDecorator(
DbContext context,
ICommandHandler<TCommand> decorated)
{
this.context = context;
this.decorated = decorated;
}
public void Handle(TCommand command)
{
this.decorated.Handle(command);
context.SaveChanges();
}
}
@H_419_6@这样可以确保您只需要编写一次此基础结构代码。任何固态DI容器都允许您配置这样的装饰器，使其ICommandHandler<T>@H_419_6@以一致的方式包装在所有实现中。
602392714
清零编程群