每个请求模式的实体框架

Question

我一直试图找到每个请求模式的EF示例。

我目前为每笔交易创建一个工作单元，但是当我在网站上这样做时，根据每个请求扩展它会更方便。

我已经使用global.asax来确定是否来自页面和/或回发的请求所以我需要将它添加到context.items。

我迄今发现的示例显示了上下文自身的包装器，但是工作单元中还有其他方法也需要，例如commit / save和dispose。

我不确定在整个场景中介绍工作单元的最佳位置 - 我是否在每次更改后简单地创建一个新的工作单元，注入上下文？

另外，鉴于请求会自然死亡，我是否需要在这种情况下处理上下文？

有人看过一些适合该法案的例子或就上述问题提供建议吗？

Answer 1

  

我迄今发现的示例显示了上下文的包装器   我自己，但工作单元内还有其他方法   也需要，例如提交/保存和处置。

还有什么其他方法？ Context提供commit（SaveChanges）和Dispose。

  

我不确定介绍工作单位的最佳位置   整个场景 - 我可以在每个场景之后创建一个新的工作单元   改变，注入上下文？

你想要工作单位吗？因此，在大多数情况下，每个请求只需要一个将所有更改保存为单个“单元”。由于某些复杂的业务逻辑，可能存在需要多个更改的情况，其中必须独立保存更改（并且它们不能通过多个SaveChanges调用通过相同的上下文保存）但在这种情况下，每个请求处理上下文当手动需要时你将不得不回到起始上下文 - 在注入方面它意味着注入上下文工厂而不是上下文实例，其中负责调用工厂获取上下文实例的组件也负责上下文的处理

如果您每个请求只需要一个上下文，则可以在Application_BeginRequest中创建它并将其置于Application_EndRequest。

Answer 2

每个请求可能应该有一个上下文。背景应该放在最后。

在请求期间可能需要使用第二个上下文来进行特殊目的，例如日志记录（您总是希望保存日志项，即使主要请求上下文从未用于保存）。

Answer 3

你需要处理上下文（即：IDisposable），我建议你使用DI容器，将你的工作单元注入其中，并设置每个请求的生命周期。

您可以在请求的生命周期内多次调用savechanges。然后，工作单元带来的便利性消失了，而如果你在请求结束时只调用一次，则会减少RTT，延迟等。