将存储库注入ASP.NET控制器的最佳方法是什么？

Question

我们有一个用ASP.NET MVC编写的项目,我们使用NInject将存储库注入控制器.目前我们正在使用属性和Inject-attribute来注入存储库,这很好用:

[Inject]
public IMyRepository MyRepos {get;set;}

注入的另一种方法是使用以下方式"手动"执行NInjectServiceLocator:

var myRepos = NInjectServiceLocatorInstance.Resolve<IMyRepository>();

现在我想知道以下内容:第一种方法要求所有存储库都列在控制器的顶部(当然不一定在顶部,但它是最合理的位置).每当发出请求时,NInject都会实例化每个存储库.无论是否在特定Action内实际需要所有存储库,都会发生这种情况.

使用第二种方法,您可以更精确地控制实际需要哪些存储库,因此在创建控制器时可能会节省一些开销.但是您可能还必须包含代码以在多个位置检索相同的存储库.

那么哪一个会更好？是否拥有一堆存储库属性更好还是更好地解决在您需要的时间和地点实际需要特定操作的存储库？注入"无用"存储库是否会导致性能下降？那里有(甚至;-)更好的解决方案吗？

Answer 1

Constructor Injection使用 DI 时应该是您的默认选择。

\n\n

您应该问自己控制器是否真的依赖于该特定类来工作。

\n\n

Method injection如果您只有需要依赖项的特定方法，也许也可以是特定场景的解决方案。

\n\n

我从未使用过Property Injection，但 Mark Seeman 在他的书中描述了它（.NET 中的依赖注入）：

\n\n

\n

仅当您正在开发的类\xe2\x80\x99 具有良好的\n 本地默认值，并且您仍希望调用者能够提供类\xe2\x80\x99s 依赖关系的不同实现\n 时，才应使用属性注入。

\n\n

当依赖项是可选的时，最好使用属性注入。

\n\n

注意围绕属性注入是否指示可选依赖项的问题存在一些争议。作为一般 API 设计原则，我认为属性是可选的，因为您很容易忘记分配它们，并且编译器不会抱怨。如果您在一般情况下接受这个原则，那么您在 DI 的特殊情况下也必须接受它。4

\n

\n\n

本地默认值描述为：

\n\n

\n

抽象的默认实现，\xe2\x80\x99 在与使用者相同的程序集中定义。

\n

\n\n

除非你正在构建 API，否则我建议不要使用属性注入

\n\n

\n

每当发出请求时，NInject 都会实例化每个存储库。无论特定操作中是否实际需要所有存储库，都会发生这种情况。

\n

\n\n

我认为使用构造函数注入时您不必太担心性能

\n