我应该在哪个级别应用依赖项注入？控制器还是域？

如何解决我应该在哪个级别应用依赖项注入？控制器还是域？

| 大家好，我想听听您在控制器级别和/或域级别应用依赖注入的主要优点和缺点。 让我解释;如果我收到IUserRepository作为用户的参数，则可以通过两种方式进行： 1）我直接在域对象上注入IUserRepository，然后在控制器级别消耗User而不更新对象，这意味着我可以从DI容器中准备好它们。 2）我将IUserRepository注入我的控制器（例如Register.aspx.cs），在那里我使用来自DI容器的依赖项来新建所有域对象。 昨天，当我与朋友交谈时，他告诉我，如果您从容器中获取域对象，则您将失去其生命周期控制，因为该容器将为您管理它，所以这意味着在处理大型xml时可能会出错。配置文件。意见不同，因为您可能有一个测试，该测试循环遍历程序集中的每个域对象，然后询问容器这是单例，请求范围，会话范围还是应用程序范围。如果其中任何一个为真，则失败。确保此类问题不会发生的一种方法。 我更倾向于使用域方法（1），因为我发现在控制器级别的重复代码行上可以节省很多钱（当然，在XML文件中将有更多行）。 我的朋友提出的另一点是，想象一下，出于任何原因，您有义务从di容器A更改为B，并说B不支持构造函数注入（对于接缝容器Java就是这样，它操纵BC或只能通过setter注入来完成其任务），好吧，他的观点是，如果我将所有代码都置于控制器级别，则可以顺利地重构代码，因为我可以使用诸如Auto-Refactoring和自动完成，当您处理XML文件时不可用。 我停留在这一点上，因为我应该立即做出决定。 我应该采用哪种方法来利用我的体系结构？ 还有其他思维方式吗？？？ 你们真的认为这是一个相关的问题，我应该为此担心吗？     

解决方法

如果要避免贫血的领域模型，则必须放弃经典的n层，n层CRUDY应用程序体系结构。格雷格·扬（Greg Young）在本文中对DDDD进行了解释。 DI不会改变这一点。 CQRS将是一个更好的选择，并且DI非常适合这种类型的体系结构倾向于产生的小型自治组件。     ,我不属于Java领域，但是根据您所提问题的详细信息，似乎您使用了某种MVC框架（因为您处理的是Controllers和domain）。但是我确实对如何在域驱动的体系结构中使用DI有意见。 首先，有几种执行DDD的方法：一些在表示中使用MVC，而MVC和Domain之间没有应用程序服务层。其他使用MVP（或MVVM），没有服务层。但是我认为有些人会同意我的看法，即您很少注入存储库（或其他服务...）。我建议将存储库注入Command（使用MVC且不使用服务层），Presenter（如果使用MVP）或Application Services（如果使用服务层）中。我主要使用一个应用程序层，在该层中，每个服务都获得需要注入构造函数中的存储库。 其次，我不必担心在IoC容器之间进行切换。如今，大多数容器框架都支持ctor注入，并且可以自动解析参数。现在，我知道您是Java开发人员，而我是MS开发人员，但是MS Practices团队有一个Common Service定位器，可以帮助您生成与所使用的容器框架完全无关的代码。 Java社区中可能有一些相似之处。 因此，选择选项2。希望我将您推向正确的方向。