我应该在哪个级别应用依赖注入?控制器或域
本文关键字：注入 控制器 依赖 应用 我应该 | 更新日期: 2023-09-27 17:50:04
我想听听您在控制器级别和/或域级别应用依赖注入的主要优点和缺点。
让我解释一下;如果我收到一个IUserRepository作为我的User的参数，我可以用两种方式进行:
-
我直接在我的域对象上注入IUserRepository，然后我在没有新对象的控制器级别消费User，这意味着，我从DI容器中准备好它们。
-
我注入IUserRepository在我的控制器(说，Register.aspx.cs)，在那里我使用依赖关系，来自DI容器新的所有域对象。
昨天，当我和朋友聊天时，他告诉我，如果你从容器中获取域对象，你就失去了它的生命周期控制，因为容器为你管理它，他的意思是在处理大型xml配置文件时，它可能容易出错。意见不一致，因为您可能有一个测试，循环遍历程序集中的每个域对象，然后询问容器是否为单例、请求范围、会话范围或应用范围。如果其中任何一个为真，它就失败了。一种确保此类问题不会发生的方法。
我认为更有可能使用域方法(1)，因为我看到在控制器级别上可以大量节省重复的代码行(当然XML文件中会有更多的行)。
另一点我的朋友玫瑰是,假设任何理由你有义务改变di容器A到B, B,说没有支持构造函数注入(这种情况对于一个 seam容器, Java,公元前操纵或只做它的任务通过setter注入),嗯,他的观点是,如果我有我所有的代码控制器级我能顺利马纳重构我的代码,我获得工具如Auto-Refactoring和自动完成,这在处理XML文件时不可用。
我被困在这一点上，因为我必须马上做出决定。
我应该采用哪种方法来利用我的体系结构? 还有其他的思考方式吗??
你们真的认为这是一个相关的问题，我应该担心吗?
如果你想避免贫血的域模型你必须放弃经典的n层，n层的CRUDY应用程序架构。Greg Young在这篇关于DDDD的文章中解释了原因。DI不会改变这个。
CQRS将是一个更好的选择，并且DI非常适合这种类型的架构倾向于产生的小型自治组件。
我不是进入Java领域，但根据您的问题中的详细信息，似乎您使用某种MVC框架(因为您处理控制器和域)。但是我对如何在领域驱动架构中使用DI有自己的看法。
首先，DDD有几种方法:一些在表示中使用MVC，在MVC和域之间没有应用服务层。其他的使用MVP(或MVVM)，没有服务层。但是我认为有些人会同意我的观点，你很少注入存储库(或其他服务……)。我建议在命令(使用MVC而不使用服务层)、演示器(如果使用MVP)或应用程序服务(如果使用服务层)中注入存储库。我主要使用应用层，其中每个服务都在构造函数中注入它们需要的存储库。
第二，我不会担心在IoC容器之间切换。如今，大多数容器框架都支持向量注入，并能自动解析参数。现在我知道您是Java开发人员，而我是MS开发人员，但是MS实践团队有一个公共服务定位器，可以帮助您生成完全不依赖于您使用的容器框架的代码。在Java社区中可能有一些类似的。
所以选择选项2。希望我把你推向了正确的方向。