我通过构造函数注入在我的项目中实现了DI，现在组合根是所有解析发生的地方（这是在web项目中），我的问题是是否创建额外的项目，只是处理解决方案是疯了。IoC和“隐藏实现细节”
这个背后的原因是我仍然在构建目录中实现程序集（因为它们仍然会被“代理”项目引用），所以我不需要在Web项目级别引用它们，反过来也就意味着这些接口的实现将不能从除实现它们之外的地方访问（除非明确引用，否则很快就会发现某些错误：你不希望这样做）。
这是一个无意义的努力可能会变得容易出错或者是一个合理的事情吗？
这有利有弊。正如BrokenGlass所说，这是一项试金石测试，另一方面，您必须小心地部署所有组件。由于包含库的依赖关系并未放入Web应用程序的bin文件夹中，因此您需要确保它们不会丢失，尽管第一次运行时您会遇到这种情况，理想情况下解决方案很简单。
这确实是一个个人喜好的问题，为了方便我喜欢在Web应用程序中添加内容，但同样可以确保这些依赖项不会泄漏到Web应用程序中。但是，如果您的项目按照您的控制器始终注入您需要的方式进行组织，那么发生这种情况的可能性就会降低。例如，如果你每控制器使用的IContext，那么你的应用使用（var context = new Context（））的可能性就会降低，因为已经设置了标准。
这是一个很好的指出部署并发症。像许多人一样，我发现在其他地方做DI映射的“纯粹性”，但实际上它不值得。 – 2012-03-01 04:00:06
@Mystere这正是我在这里质疑的平衡点，“值得吗？”问题在于：“利大于弊吗？” – bevacqua 2012-03-01 04:04:55
@Nico - 只有你可以回答。我个人认为它不值得。这听起来像亚当和BrokenGlass也不（但我不想在他们的嘴里说话）。但我知道很多人做我认为不值得的事情，因为对他们来说是这样。 – 2012-03-01 04:08:43
这根本不是疯了 - 这是一个非常好的试金石测试，以确保没有依赖关系潜入并且非常有用。这只会在你的抽象/接口被定义在与实现这些接口的具体类不同的程序集中定义的情况下起作用。我说过，个人而言，我一直将聚合根保存在主Web应用程序的程序集中，这个额外的程序集中包含额外的工作，并且由于我大部分只是注入接口，所以我并不太担心它，因为我主要关心的是真正的可测试性。可能有项目虽然这是一个有价值的方法。
我不是在“代理”项目的目的明确。它似乎是从Web应用程序中移除直接依赖关系到实现，并且目标是插件模型。但是，如果是这种情况，那么您只需添加一个间接级别即可。 您是否考虑过使用MEF来完成外部程序集的编译时未知的实现组合？它旨在做到这一点。 – jonsequitur 2012-03-01 03:48:20
相关：http://stackoverflow.com/questions/9501604/ioc-di-why-do-i-have-to-reference-all-layers-assemblies-in-entry-application/9503612#9503612 – 2012-03-01 07:21:02