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