3
我在我的MVC应用程序中使用存储库模式。每个存储库都包含数据检索方法，如GetByID，GetByXXXX，GetByYYYY。如果我需要从其他实体的控制器执行这些方法，我需要为该操作实例化该存储库。 你认为这种方式对于系统来说是昂贵的吗？我应该还是不让这些方法是静态的？ 谢谢！MVC存储库模式 - 昂贵的实例化，静态方法？
A
回答
1
实例化一个仓库不是一个昂贵的操作特别当与Web请求的正常往返时间进行比较时。如果存储库是只读的，那么在使用静态实例时没有问题，但如果它是可读写的，则每个请求都需要一个单独的存储库。
+0
静态GetXXX方法如何干扰其他回购？ – Jim 2011-03-29 00:57:36
+1
@Jim，你用这些方法获得了你的实体的状态 - 这就是为什么你最好不要让它变成静态的。如果不涉及状态，可以使方法静态 - 例如如果你可以很容易move'em分开静态助手类。如果没有 - 最有可能的是你处理版本库的状态，并且不能使repo方法调用的上下文静态化。 – 2011-03-29 07:46:21
1
你不应该让它们成为静态的。您应该使用IoC容器来执行依赖注入。
这里是一个代码示例：Entity Framework 4 CTP 4/CTP 5 Generic Repository Pattern and Unit Testable
帖子上期运用IOC容器： 的NuGet为Structuremap：http://nuget.org/List/Packages/StructureMap-MVC3
博客文章：http://www.bengtbe.com/blog/post/2009/02/27/Using-StructureMap-with-the-ASPNET-MVC-framework.aspx
+1
OMG，一个抽象层次？所有好的MVC appsshoul使用DI/IoC？ （我刚刚开始使用MVC ...） – Jim 2011-03-29 00:50:56
+0
MVC入门，花点时间，尽你所能实现。然而，使用IoC/DI的工作对我来说很有帮助，它真的帮助开始将各种代码分成更小，更易于管理的单元。是的，这是一个额外的层次，首先要管理更多，但在应用程序的整个生命周期中，值得为可维护性付出努力。 – reallyJim 2011-03-29 02:32:47
+1
@Jim - DI实际上与MVC无关。这是S.O.L.I.D原则的一部分。您可以在这里了解更多关于S.O.L.I.D的信息：http://www.dimecasts.net/Casts/ByTag/SOLID%20原理S.O.L.I.D中的D是依赖倒置原则。我建议观看整个系列。 – Paul 2011-03-29 02:40:46
1
就像我们都说的那样，我会说“这取决于”。就像保罗在他的回答中提到的那样，使用依赖注入是很好的 - 但是不管你是否确实对你的问题的核心没有影响。
我已经把几个应用程序做，但你的代码是在构造函数中使用DI
private ISomeInjectedType myRepository;
public SomeController(ISomeInjectedType type)
{
myRepository = type;
}
或只是实例类型
private ISomeType myRepository;
public SomeController()
{
myRepository = new SomeType();
}
你基本上得到相同的结果出来的代码 - 离开可维护性的论据。
我已经通过DI方法为大量应用程序完成了这项工作，并且从性能角度发现了零缺陷 - 即使无意中有一个团队有点失去控制并且注入/创建了大约12个为每个控制器构造函数创建的“存储库”。
无论哪种方式，无论哪种方式最适合你。你提到你正在开始使用MVC。我的想法是肯定的，使用DI，但是当你准备好后再做。
采取您需要的小步骤来启动并运行，然后根据需要提前启动它们。
0
版本库实例化不是性能代价高昂的操作，也不是创建ORM会话（不管是NHibernate ISession还是EF ObjectContext）。不要进行不必要的微观优化，并使用IoC工具武装自己，以轻松，透明地注入所有存储库依赖项（比第一次使用它之前似乎更简单）。
静态方法是没有办法有帮助这里bacause你不处理静态上下文（你应该有你的ORM会议的具体实例 - 这是一个状态 - 你不能够使用它在静态上下文中）。
有趣的存储库模式采取：http://goo.gl/VyP6t – 2011-03-29 00:53:16