我通过构造函数注入在我的项目中实现了DI，现在组合根是所有解析发生的地方（这是在web项目中），我的问题是创建一个只处理解析的附加项目的想法疯了。
这背后的原因是我仍然在构建目录中有实现程序集（因为它们仍然会被“代理”项目引用），我不需要在Web项目级别引用它们，这在转而意味着这些接口的实现将无法从除了它们实现之外的其他地方访问（除非明确引用，这将很快指出出现问题：你不想这样做）。 p>
这是一种无意义的努力，可能容易出错或者是否合理？
答案 0 :(得分：2)
这根本不是疯了 - 这是一个非常好的试金石，以确保没有依赖性潜入并且非常有用。只有当您的抽象/接口在不同的程序集中定义而不是实现这些接口的具体类时，这才有效。
话虽如此，我个人总是将聚合根保留在主Web应用程序集中，这个额外的程序集需要额外的努力，因为我在大多数情况下只注入接口我不太担心它，因为我主要担心的是可测试性。可能有一些项目，这是一个值得的方法。
答案 1 :(得分：2)
这有利有弊。正如BrokenGlass所说，这是一个试金石，另一方面，你必须小心部署所有的组件。由于包含的libs的依赖关系不会被放入Web应用程序的bin文件夹中，因此您需要确保它们不会被遗漏，尽管在第一次运行时您会遇到这种情况并且理想情况下解决方案很容易。
这确实是个人偏好的问题，为了方便我想要包含在Web应用程序中，但同样，它可以确保这些依赖关系不会泄漏到Web应用程序。但是，如果您的项目按照控制器总是注入所需要的方式进行组织，那么它的发生几率就会降低。例如，如果您在每个控制器中使用IContext，那么您不太可能在应用中使用（var context = new Context（）），因为已经设置了标准。
答案 2 :(得分：0)
您可以进行一些构建后处理，以确保实现不会泄漏。
干杯 Tymek