我应该在哪个级别应用依赖注入？控制器还是域？
我想听听您在控制器级别和/或域级别应用依赖注入的主要优点和缺点是什么。
让我解释一下；如果我收到一个 IUserRepository 作为我的 User 的参数，我可以通过两种方式进行：
我直接在我的域对象上注入 IUserRepository，然后在控制器上使用 User没有新建对象的级别，这意味着我从DI容器中准备好它们。
我在控制器上注入 IUserRepository（例如 Register.aspx.cs），然后使用来自 DI 容器的依赖项新建所有域对象。
昨天，当我和我的朋友交谈时，他告诉我，如果你从容器中获取域对象，你就会失去其生命周期控制，因为容器会为你管理它，他的意思是它可能容易出错
我更有可能使用域方法 (1)，因为我发现控制器级别的重复代码行可以节省大量（当然 XML 文件中会有更多行）。
我的朋友罗斯提出的另一点是，想象一下，出于任何原因，您有义务从容器 A 更改为 B，并说 B 不支持构造函数注入（seam 容器就是这种情况） ，Java，它操纵 BC 或仅通过 setter 注入执行其任务），好吧，他的观点是，如果我将所有代码都放在控制器级别，我就能够以顺利的方式重构我的代码，因为我可以访问自动重构等工具自动完成，在处理 XML 文件时不可用。
我现在陷入困境，因为我应该立即做出决定。
我应该利用哪种方法来利用我的架构？ 还有其他思考方式吗？？？
你们真的认为这是一个相关的问题吗，我应该担心吗？
I would like to hear from you what are de the main advantages and drawbacks in applying dependency injection at the controller level, and/or domain level.
Let me explain; if I receive a IUserRepository as param for my User, I may proceed in two ways:
I inject IUserRepository direct on my domain object, then I consume User at controller level without newing objects, it means, I get them ready from the DI container.
I inject IUserRepository on my controller (say, Register.aspx.cs), and there I new all my domain objects using dependencies that came from the DI container.
Yesterday, when I was talking to my friend, he told me that if you get your domain objects from the container you loose its lifecicle control, as the container manages it for you, he meant that it could be error prone when dealing with large xml configuration files. Opinion which disagree as you may have a tests that loops through every domain object within an assembly and then asks the container whether thats a singleton, request scope, session scope or app escope. It fails if any of them are true. A way of ensuring that this kind of issue wont happen.
I fell more likely to use the domain approach (1), as I see a large saving on repetitive lines of code at controller level (of course there will be more lines at XML file).
Another point my friend rose was that, imagine that for any reason youre obligated to change from di container A to B, and say that B has no support for constructor injection (which is the case for a seam container, Java, which manipulates BC or only do its task via setter injection), well, his point is that, if I have all my code at controller level I'm able to refactor my code in a smoothly maner, as I get access to tools like Auto-Refactoring and Auto-Complete, which is unavailable when youre dealing with XML files.
Im stuck at this point, as I should have a decision to make right away.
Which approach should I leverage my architecture?
Are there other ways of thinking???
Do you guys really think this is a relevant concern, should I worry about it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您想避免贫乏的域模型，您必须放弃经典的 n 层、n 层 CRUDY 应用程序架构。 Greg Young 在这篇关于 DDDD 的论文中解释了原因。 DI 不会改变这一点。
CQRS 将是一个更好的选择，DI 非常适合这种类型的架构往往产生的小型自治组件。
If you want to avoid an anemic domain model you have to abandon the classic n-tier, n-layer CRUDY application architecture. Greg Young explains why in this paper on DDDD. DI is not going to change that.
CQRS would be a better option, and DI fits very well into the small, autonomous components this type of architecture tends to produce.
我不熟悉 Java 领域，但根据您问题中的详细信息，您似乎使用了某种 MVC 框架（因为您处理控制器和域）。但我对如何在域驱动架构中使用 DI 确实有自己的看法。
首先，有几种实现 DDD 的方法：有些在表示中使用 MVC，并且在 MVC 和域之间没有应用程序服务层。其他使用 MVP（或 MVVM）并且没有服务层。但我认为有些人会同意我的观点，即你很少注入存储库（或其他服务......）。我建议在 Command（使用 MVC 且无服务层）、Presenter（如果您使用 MVP）或应用程序服务（如果您使用服务层）中注入存储库。我主要使用应用程序层，其中每个服务都获取它们需要注入到构造函数中的存储库。
其次，我不担心 IoC 容器之间的切换。如今大多数容器框架都支持 ctor 注入，并且可以自动解析参数。现在我知道您是一名 Java 开发人员，我是一名 MS 开发人员，但 MS Practices 团队有一个公共服务定位器，可以帮助您生成与您使用的容器框架完全无关的代码。 Java 社区中可能也有一些类似的东西。
所以选择选项 2。希望我能把你推向正确的方向。
I'm not into the Java sphere, but according to your details in your questions it seems like you use some kind of MVC framework (since you deal with Controllers and domain). But I do have an opinion about how to use DI in a Domain Driven architecture.
First there are several ways of doing DDD: Some uses MVC in presentation and no application service layer between MVC and Domain. Other uses MVP (or MVVM) and no service layer. BUT I think some people will agree on me that you very rarely inject repositories (or other services...). I would recommend to inject Repositories in Command (using MVC and no service layer), Presenter (if you use MVP) or Application Services (if you use service layer). I mostly use an application layer where each service get the repositories they need injected in constructor.
Second I wouldn't worry about switching between IoC containers. Most container framework today support ctor injection and can auto-resolve parameters. Now I know that you're a Java developer and I'm a MS developer, but MS Practices team has a Common Service locator that can helps you in producing code that are extremely non-dependent of which container framework you uses. There is probably some similar in the Java community.
So go for option 2. Hope I pushed you into right direction.