MVC3脚手架存储库中的Singleton DbContext派生对象

Question

我在MVC4应用程序和Ninject.MVC3中使用EF 4.3。 控制器使用-Repository开关进行MVCscaffolded。 MVCScaffolder使用EF进行数据访问，其中DbContext派生对象始终作为每个脚手架存储库中的数据成员“新建”，从而创建存储库类（和相应的IRepository接口）。

MyContext context = new MyContext(); 

脚手架控制器的性质使得对于每个控制器，您通常也会获得相应的存储库。

问题：

1）是否有意义有对你有一个控制器，每个域对象存储库？ 与存储库模式相比，这似乎违反直觉，其中只有聚合根应该暴露于
。

2）是否有意义有每次产生的 存储库对象被实例化一个的DbContext派生对象的新实例或是否有意义有一个与DI容器上注册的 的DbContext派生对象的单一实例应用程序启动并解决它在 单库，像这样：

Bind<MyContext>().To<MyContext>().InSingletonScope(); //ninject code on app startup 


//resolve context in repositories: 
MyContext context = ServiceLocator.Current.GetInstance<MyContext>(); 

有什么缺点持有到一个派生的DbContext对象作为 单为应用程序的生命周期？

谢谢。

Answer 1

1. 这取决于你的期望。如果你想使用真正的仓库，你将使用聚合根，你将自己编写这些仓库（不自动生成），因为这样的仓库总是特定的。如果你只是想generic wrapper around EF你会使用你当前的解决方案。 T
2. 对于您的控制器必须使用多个存储库并且必须协调将所有存储库中的数据保存在一起（工作单元模式）的场景，通常会根据HTTP请求使用新的上下文。 Don't use singleton context!