我应该在哪个级别应用依赖注入？控制器或域名？

Question

嘿伙计们,我想听听你在控制器级别和/或域级别应用依赖注入的主要优点和缺点是什么.

让我解释; 如果我收到IUserRepository作为我的用户的参数,我可以通过两种方式进行:

1)我直接在我的域对象上注入IUserRepository,然后在没有新对象的情况下在控制器级别使用User,这意味着,我从DI容器中准备好它们.

2)我在我的控制器上注入了IUserRepository(比如Register.aspx.cs),然后我使用来自DI容器的依赖项新建了所有域对象.

---

昨天,当我和我的朋友交谈时,他告诉我,如果你从容器中获取你的域对象,你就会失去它的生命周期控制,因为容器为你管理它,他的意思是在处理大型xml时它可能容易出错.配置文件.意见不一致,因为您可能有一个测试循环遍历程序集中的每个域对象,然后询问容器是单例,请求范围,会话范围还是应用程序escope.如果它们中的任何一个是真的,它就会失 确保此类问题不会发生的一种方法.

我更倾向于使用域方法(1),因为我看到在控制器级别上重复的代码行节省了很多(当然XML文件中会有更多的行).

我的朋友提出的另一点是,想象一下,由于任何原因,你有义务从di容器A改为B,并且说B不支持构造函数注入(对于一个接缝容器,Java,它操纵BC或者只有通过setter注入完成它的任务),他的观点是,如果我在控制器级别拥有所有代码,我就能够以平滑的方式重构我的代码,因为我可以访问Auto-Refactoring和Auto等工具-Complete,在处理XML文件时不可用.

我坚持这一点,因为我应该立即做出决定.

我应该利用我的架构采用哪种方法？ 还有其他的思维方式吗？

你们真的认为这是一个相关的问题,我应该担心吗？

Answer 1

如果你想避免贫血领域模型,你必须放弃经典的n层,n层CRUDY应用程序架构.Greg Young解释了为什么在这篇关于DDDD的论文中.DI不会改变这一点.

CQRS将是更好的选择,DI非常适合这种类型的架构倾向于产生的小型自治组件.