c# - 在 ASP.NET MVC 4 解决方案中配置编译时依赖注入(inject)的依赖倒置

Question

我一直在研究如何设计一个 MVC 4 网络解决方案，该解决方案遵循依赖倒置原则并利用配置流畅(即具有编译时类型检查)的依赖注入(inject) (DI) 容器。

ASP.NET MVC 4 Dependency Injection的很多例子我发现将重点放在将 DI 实现到 MVC 框架提供的入口点的细节上。我发现自己倾向于由此产生的分层方法(依赖关系用红色箭头显示): 不幸的是，这重复了传统的依赖模型，其中高级模块依赖于低级模块。遵循依赖倒置的原则，IService 接口(interface)被移动到 WebProject 中。不幸的是，这会在两个项目之间创建循环引用: 为了避免循环引用，CompositionRoot 被移动到它自己的项目中:

留给我如何引导容器的问题(现在我不能直接从 WebProject 中引用它)？

在 the best way to get the directory from which an assembly is executing 的帮助下可以通过反射实现初始化。

var assembly = System.Reflection.Assembly.LoadFile(Helper.AssemblyDirectory + "/DependencyInjectionProject.dll");
var type = assembly.GetType("DependencyInjectionProject.Bootstrapper");
IDependencyResolver resolver = (IDependencyResolver)type.GetMethod("Initialise").Invoke(null, null);
DependencyResolver.SetResolver(resolver);

为了简化构建，我将 DependencyInjectionProject 的构建目标设置为 WebProject bin 目录。我达到了我的目标；反向依赖项和编译时检查容器配置，但由于在 IIS Express 中运行 WebProject 时经常发生构建目标冲突，我对这种方法并不完全满意。

我非常有兴趣了解满足这些要求的其他经验和方法。我应该放弃编译时配置并采用基于文本的配置吗？是否有明显的层结构可以避免我没有看到的循环依赖陷阱？

Answer 1

Composition Root 与 DI Container 不同。 Composition root是可执行文件最早期的入口层，DI Container就放在那里。

DI Container 放在那里的原因之一是，入门级没有被任何其他类调用。所以当你在那里创建 DI Container 时，它会确保 DI Container 在最早调用时构建，并防止空引用异常。可能还有其他好处，但我只是不知道。

我常用的是分层设计，包括:

1. 领域模型(实体)
2. 接口(interface)(引用 1)
3. 服务(引用 1 和 2)
4. dal(引用文献 1 和 2)
5. 用户界面(引用 1、2、3、4)

这种设计一定要优先选择好的SOC，并且可以防止UI直接访问版本库。 dal 不了解服务和 UI。该服务不知道 DAL 和 UI。

我知道的一个缺点是这种设计允许 UI 直接访问 DAL 而无需服务。

虽然我仍然不知道这种设计的其他缺点。