ASP.NET MVC 按请求注入
我需要为每个请求注入 EF 上下文。有没有办法实现呢?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
我需要为每个请求注入 EF 上下文。有没有办法实现呢?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(3)
您是否查看过 这个关于 Unity 和 ASP.NET MVC DI 的优秀博客?
应该让你走上正轨。
答案是是,您可以 - 本文将向您展示如何操作。
简而言之,您创建一个 HttpContextLifetimeManager 来处理对象的“范围”。容器将实例“缓存”在 HTTP 上下文中。
这是必需的,因为 Unity 提供的默认生命周期管理器不涵盖“现成的”HTTP 上下文范围。
当然,其他 DI 容器(例如我使用的 StructureMap)也可以。
这里是关于同一事物的另一篇(更新的)文章,以“Nerdinner”为例。
Did you check out this excellent blog on DI with Unity and ASP.NET MVC?
Should get you on the right track.
The answer is yes, you can - and the article shows you how.
In short, you create a HttpContextLifetimeManager to handle the "scoping" of your objects. The container "caches" the instance in the HTTP Context.
This is needed because the default life time managers provided by Unity don't cover HTTP Context scoping "off the shelf".
Of course, other DI container's (such as StructureMap - which i use), do.
Here is another (more up to date) article on the same thing, with the "Nerdinner" as the example.
Unity 讨论列表中的建议的解决方案是为每个请求,让该子容器创建 EF 上下文作为 ContainerControlledLifetime,然后在请求结束时处置该子容器。通过这样做,您不必创建自定义 LifetimeManager。
我对Unity不是很熟悉,但原理是这样的:
The solution proposed in the Unity Discussion list is to create a child container per request, have that child container create the EF context as ContainerControlledLifetime, then have the child container disposed at the end of the request. By doing so you don't have to create a custom LifetimeManager.
I'm not very familiar with Unity but the principle would be something like this:
你说的注射是什么意思?你的意思是应用依赖倒置原则吗?如果是,那么您是否曾设想过将 EF 上下文替换为遵守相同合同的其他上下文?
对我来说,您应该将 EF 上下文封装在框架中的某个位置,以便每个请求都能获取 EF DataContext。在您的存储库上应用 DI。稍后您的存储库可能有不同类型的上下文,您可以相互切换存储库。
What do you mean by injecting? Do you mean to apply dependency inversion principle on it? If yes then do you ever envisage yourself swapping out your EF context with some other context which adheres to same contract?
To me you should encapsulate EF context somewhere in framework, so that every request gets EF DataContext. Apply DI on your repository. Later on your repositories might have different kind of contexts and you can switch repositories with each other.