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

嗨，大家好，我希望听到您在控制器级别和/或域名级别应用依赖注入时的主要优点和缺点。我应该在哪个级别应用依赖注入？控制器或域？

让我解释一下;如果收到一个IUserRepository作为PARAM我用户，我可以进行以下两种方式：

1）I注入IUserRepository直接我的域对象上，然后我消耗用户在控制器级别而不newing对象，这意味着，我从DI容器准备好它们。

2）我在我的控制器（比如说Register.aspx.cs）注入IUserRepository，并且在那里我使用了来自DI容器的依赖的新的所有域对象。

昨天，当我说我的朋友，他告诉我，如果你从你失去它lifecicle控制容器让你的域对象，如容器管理它适合你，他的意思是，它可能是容易出错处理大型xml配置文件时。意见不一致，因为你可能有一个循环遍历程序集中每个域对象的测试，然后询问容器是否是单例，请求范围，会话范围或应用程序范围。如果其中任何一个都是真的，它就会失败确保这种问题不会发生的一种方法。因为我看到在控制器级别重复的代码行上有很大的节省（当然在XML文件中会有更多的行），所以我更倾向于使用域方法（1）。

我的朋友玫瑰的另一点是，假设由于任何原因，你有义务从容器A更换为B，并且说B不支持构造器注入（接缝容器的情况， Java，它操纵BC或者只通过setter注入完成它的任务），好的，他的观点是，如果我将所有的代码都放在控制器级别，我就可以平滑地重构我的代码，因为我可以访问工具如自动重构和自动完成，这在处理XML文件时不可用。

我在这一点上陷入困境，因为我应该立即做出决定。

哪种方法应该利用我的架构？ 有没有其他的思考方式？

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

来源

2011-04-12 renatoargh

为什么用户应该知道IUserRepository？ – 2011-04-12 20:38:31

因为我完全决定我不会使用ANEMIC DOMAIN MODEL，所以我决定像.Save（）或.Update（）这样的方法应该是实体本身的一部分，当然也要把这些努力委派给这些对象主要倾向于它，它意味着存储库。因为我想以分离的方式工作，不让我的应用成为一个巨大的monolitic应用，我决定域定义它的存储库接口，而其他组合将由于使用它，因为发生DI需要注入在我的域对象中使用具体的存储库实体（我在每个ctor中都使用guard子句） – renatoargh 2011-04-12 20:46:28

@Renato Gama听起来更像是一个活动记录模式，可能对它有所帮助。当您需要服务时，我宁愿看到IoC在工作，但不希望在创建实体时出现贫血。我认为主动记录模式通过某个单身人士到达实际的实体持有者。更多的是，保存和更新通常是实体的静态方法，而不是实例方法。 – 2011-04-12 20:49:33

如果你想避免贫血域模型你必须放弃传统的n层，n层CRUDY应用程序体系结构。 Greg Young解释了为什么在this paper on DDDD。 DI不会改变这一点。

CQRS会是一个更好的选择，并且DI非常适合这种类型的体系结构倾向于产生的小型自治组件。

来源

2011-04-12 21:01:02

我没有进入Java领域，但根据你的问题的细节，你似乎使用某种MVC框架（因为你处理控制器和域）。但是我对如何在域驱动体系结构中使用DI有一些看法。

首先有几种做DDD的方法：有些在演示中使用MVC，在MVC和Domain之间没有应用服务层。其他使用MVP（或MVVM）并且没有服务层。但我想有些人会同意我的看法，你很少注入存储库（或其他服务......）。我建议在命令（使用MVC和无服务层），Presenter（如果使用MVP）或应用程序服务（如果使用服务层）中注入存储库。我主要使用应用程序层，其中每个服务都会在构造函数中获取它们需要注入的存储库。

第二我不会担心在IoC容器之间切换。今天的大多数容器框架都支持ctor注入，并且可以自动解决参数。现在我知道你是Java开发人员，而且我是MS开发人员，但MS Practices团队有一个通用服务定位器，可以帮助您生成与您使用的容器框架无关的代码。在Java社区中可能有些类似。

所以去选项2.希望我把你推向正确的方向。

来源

2011-04-12 21:01:36

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

回答

相关问题