我有一个视图，我在我的数据库中搜索一个对象（即书籍）..
此视图的控制器取决于实现搜索方法的BooksRepository。
一切正常。我还可以选择进行高级搜索，在模态弹出窗口中显示更大的表单。此表单包含许多字段，包括用于选择要搜索的“作者”的下拉框。
我想在我的viewmodel中传递一个authors列表，所以在我的控制器中我实例化了我的视图模型的一个实例，我需要调用一个存储库方法来恢复authors的列表的...
我的想法是这个GetAuthors（）方法应该在AuthorRepository ...
中将多个repo注入控制器是不好的做法？或者我应该有一个作者控制器注入作者repo ...并从我的BookSearch控制器调用作者控制器中的方法？
答案 0 :(得分：11)
我认为在控制器中引用多个存储库是完全正确的。控制器的工作是将数据包装在模型中并将其传递给视图，而不管它是如何访问数据的。执行跨控制器调用可能会变得混乱。
答案 1 :(得分：4)
我认为将所需的两个存储库注入控制器并不是一个坏主意。实际上这听起来不错。
但是如果你觉得事情已经失控，你可能想要创建一个应用程序服务，它可以编排一个可以注入多个存储库的函数。这也是一种将逻辑从控制器移开的方法。
但在这种情况下，我认为你做得对。
阅读本书：http://www.infoq.com/minibooks/domain-driven-design-quickly
答案 2 :(得分：2)
就个人而言，我认为书籍和作者都是非常具体的实体....除非你打算让作者写一首歌，你想拥有一个音乐库和一个书库，我会可能会将作者和书籍保存在同一个存储库中，因为您很可能同时需要它们。
即使这样，您也可以拥有一个音乐存储库和一个书库，它们都来自同一作者表。这没什么不对。不，在控制器中拥有多个存储库并不是“禁忌”，但除非您使用依赖注入，否则在添加更多存储库时它会变得毛茸茸。
答案 3 :(得分：1)
我有几个控制器引用了多个存储库。如果每个存储库都实例化自己的数据上下文（或EF ObjectContext），请小心。就实体框架而言，如果您开始使用两个打开的上下文来导航实体引用，那么您将遇到问题。
除此之外，它对我来说很好。
答案 4 :(得分：0)
从架构师的角度来看。
如果您觉得您的mvc控制器与依赖关系失控，那么就该考虑两件事了。
查看设计并确定是否需要外观类来表示复杂的子系统，除了它更适合单元测试（还有4层应用程序）
看一下其他一些设计模式可以帮助解决这个问题，直到它变成一个问题（可能是DI的战略，访问者）
另外，我敢打赌在这种情况下，单元测试更加痛苦，如果你不能以简单的方式对其进行单元测试，那么它应该被标记为改进
祝你好运，