实体框架通用存储库生命周期
我读过几篇有关在实体框架中创建通用存储库的文章。在每篇文章中，ObjectContext 都作为参数传递给构造函数，如下所示：
public Repository(ObjectContext context)
{
_context = context;
}
在 Web 应用程序中，处理 ObjectContext 生活方式的首选方式是按 Web 请求。这意味着，如果在 Web 环境中使用，这些存储库还必须具有每个 Web 请求的生活方式。如果我们坚持构造函数注入，这种情况会传播到使用存储库的服务，并且进一步传播......
我认为 ObjectContext 生命周期应该在存储库外部处理，例如在 HttpModule 中。 我还想将存储库作为单例来处理，然后 ObjectContext 就无法注入到构造函数中。 必须使用另一种将 ObjectContext 放入存储库的机制，例如 ObjectContextFactory。
以单例方式处理存储库有什么缺点？
I've read a couple of articles about creating a generic repository in Entity Framework. In every article the ObjectContext is passed as an argument to the constructor like this:
public Repository(ObjectContext context)
{
_context = context;
}
In a web application the preferred way to handle ObjectContext lifestyle is per web request. This means that these repositories must also have lifestyle per web request, if used in in a web context. This spreads to services using repositories and further on if we stick to constructor injection...
I think the ObjectContext life cycle should be handled outside the repositories, for example in a HttpModule. I would also like to handle repositories as singletons instead, and then ObjectContext can't be injected in the constructor. Another mechanism for getting the ObjectContext into the repository must be used, like an ObjectContextFactory.
Whats the downside of handling the repositories with a singleton lifestyle?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
与任何其他对象一样，存储库是单例的一个问题是确定存储库具有哪些依赖关系变得更加困难。当您需要在构造函数中传递上下文时，这是对 ObjectContext 类的依赖关系的明确声明。如果您要使用静态工厂来获取对对象上下文的引用，则有必要查看存储库的实现以了解它如何使用工厂。
实现您正在寻找的内容（即管理存储库外部的 ObjectContext 类的范围的能力）的一种常见方法是使用依赖项注入库，例如 Autofac.您可以注册 ObjectContext 类，以便为每个 HTTP 请求创建一个新实例。然后，如果您还注册了存储库类，则当请求存储库时，依赖项注入容器将尝试获取对 ObjectContext 依赖项的引用。由于每个 HTTP 请求只会创建一个 ObjectContext 实例，因此该范围内的多个存储库将收到相同的实例。 Autofac 页面有与 ASP.NET 集成的示例，您可以查看。
One issue with repositories being singletons, as with any other objects, is that determining what dependencies the repository has becomes more difficult. When you require that a context is passed in the constructor that is a clear declaration of a dependency on the ObjectContext class. If you were to use a static factory to get a reference to an object context then it would be necessary to see the implementation of the repository to know how it uses the factory.
A common way to achieve what you're looking for, namely the ability to manage the scope of the ObjectContext class outside of the repository is by using a dependency injection library, such as Autofac. You can register the ObjectContext class such that a new instance is created for every HTTP request. Then if you also register the repository class, when a repository is requested the dependency injection container will attempt to get a reference to the ObjectContext dependency. Since only one instance of ObjectContext will be created per HTTP request multiple repositories within that scope will receive the same instance. The Autofac page has example of integrating with ASP.NET that you can look at.