我一直在尝试查找每个请求模式的 EF 示例。
我目前为每笔交易创建一个工作单元，但是当我在网站上这样做时，根据每个请求扩展它会更方便。
我已经使用 global.asax 来确定请求是否来自页面和/或回发，所以我需要做的就是将我的对象添加到 context.items。
迄今为止我发现的示例显示了上下文本身的包装器，但在工作单元中还需要其他方法，例如提交/保存和处置。
我不确定在整个场景中引入工作单元的最佳位置 - 我是否在每次更改后简单地创建一个新的工作单元，注入上下文？
另外，鉴于请求会自然终止，我是否需要在这种情况下处理上下文？
有人看过一些符合要求的例子或就上述问题提供建议吗？
【问题讨论】：
标签： .net entity-framework repository-pattern unit-of-work
迄今为止我发现的示例显示了上下文的包装器 本身，但在工作单元中还有其他方法 也需要，例如提交/保存和处置。
还有什么方法？上下文提供了提交 (SaveChanges) 和 Dispose。
我不确定介绍工作单元的最佳位置，在 整个场景 - 我是否在每个场景之后简单地创建一个新的工作单元 改变，注入上下文？
你想要工作单元吗？因此，在大多数情况下，每个请求只需要一个，即可将所做的所有更改保存为一个“单元”。在某些情况下，由于某些复杂的业务逻辑必须独立保存更改（并且它们不能通过多个SaveChanges 调用简单地保存在同一上下文中），您可能需要多个，但在这种情况下，每个请求的处理上下文将不会工作，当需要手动启动上下文时，您将不得不回到启动上下文 - 就注入而言，这意味着注入上下文工厂而不是上下文实例，其中负责调用工厂以获取上下文实例的组件也负责上下文的处置。
如果每个请求只需要一个上下文，您可以在 Application_BeginRequest 中创建它，然后在 Application_EndRequest 中处理它。
【讨论】：
您可能应该为每个请求提供一个上下文。上下文应该放在它的末尾。
在请求期间可能需要使用第二个上下文以用于特殊目的，例如日志记录（您总是希望保存日志项，即使主请求上下文从未用于保存）。
【讨论】：
您需要处理上下文（即：IDisposable），我建议您使用 DI 容器，将您的工作单元注入其中，并设置每个请求的生命周期。
您可以在请求的生命周期内多次调用 savechanges。那么工作单元带来的便利就消失了，而如果你在请求结束时只调用一次，你可以减少 RTT、延迟等。
【讨论】：