嗨伙计们，我想听听您在控制器级别和/或域级别应用依赖项注入的主要优点和缺点。
让我解释一下;如果我收到 IUserRepository 作为用户的参数，我可以采取两种方式：
1）我直接在我的域对象上注入IUserRepository，然后在没有新对象的情况下在控制器级别使用User，这意味着，我从 DI容器中准备好它们。
2）我在我的控制器上注入IUserRepository（比如Register.aspx.cs），然后我使用来自 DI容器的依赖关系新建了我的所有域对象。
昨天，当我和我的朋友交谈时，他告诉我，如果你从容器中获取你的域对象，你就会失去它的生命周期控制，因为容器为你管理它，他的意思是它可能错误处理大型xml配置文件时容易出现。意见不一致，因为您可能有一个测试循环遍历程序集中的每个域对象，然后询问容器是单例，请求范围，会话范围还是应用程序escope。如果它们中的任何一个是真的，它就会失确保不会发生此类问题的方法。
我更倾向于使用域方法（1），因为我看到在控制器级别上重复的代码行节省了很多（当然XML文件中会有更多行）。
我朋友的另一个观点是，想象一下，由于任何原因你有义务从di容器A改为B，并且说B不支持构造函数注入（接缝容器的情况< / em>，Java，它操纵BC或只通过setter注入完成它的任务），他的观点是，如果我在控制器级别拥有所有代码，我能够以平滑的方式重构我的代码，就像我一样可以访问自动重构和自动完成等工具，这些工具在处理XML文件时不可用。
我坚持这一点，因为我应该立即做出决定。
我应该采用哪种方法来体现我的架构？ 还有其他的思考方式吗？
你们真的认为这是一个相关问题吗，我应该担心吗？
答案 0 :(得分：5)
如果您想避免贫血领域模型，您必须放弃经典的n层，n层CRUDY应用程序架构。 Greg Young在this paper on DDDD中解释了原因。 DI不会改变它。
CQRS将是一个更好的选择，DI非常适合这种类型的架构倾向于产生的小型自治组件。
答案 1 :(得分：1)
我不是在Java领域，但根据你在问题中的详细信息，你似乎使用某种MVC框架（因为你处理控制器和域）。但我确实对如何在域驱动架构中使用DI有一个看法。
首先有几种方法可以做DDD：有些使用MVC进行演示，而MVC和Domain之间没有应用服务层。其他使用MVP（或MVVM）而没有服务层。但我认为有些人会同意我很少注入存储库（或其他服务......）。我建议在Command中注入存储库（使用MVC而不是服务层），Presenter（如果使用MVP）或Application Services（如果使用服务层）。我主要使用一个应用程序层，其中每个服务都获取他们需要在构造函数中注入的存储库。
其次我不担心在IoC容器之间切换。今天大多数容器框架支持ctor注入并且可以自动解析参数。现在我知道你是一名Java开发人员，而且我是一名MS开发人员，但MS Practices团队有一个公共服务定位器，可以帮助您生成非常依赖于您使用的容器框架的代码。 Java社区中可能有类似的东西。
所以请选择2.希望我把你推向正确的方向。