我一直在研究如何设计一个 MVC 4 Web 解决方案,该解决方案遵循依赖倒置原则,并利用配置流畅的依赖注入 (DI) 容器(即编译时类型检查)。
ASP.NET MVC 4 依赖注入的许多示例我发现重点关注在 MVC 框架提供的入口点中实现 DI 的细节。我发现自己倾向于最终的分层方法(用红色箭头显示的依赖关系):
不幸的是,它重复了传统的依赖模型,其中高级模块依赖于低级模块。遵循依赖倒置的原则,IService 接口被移动到 WebProject 中。不幸的是,这在两个项目之间创建了一个循环引用:
为了避免循环引用,CompositionRoot 被移动到它自己的项目中:
给我留下了如何引导容器的问题(现在我不能从 WebProject 中直接引用它)?
在获取程序集执行初始化的目录的最佳方法的帮助下,可以通过反射来实现。
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 时经常发生构建目标冲突。
我很想听听其他经验和方法来满足这些要求。我应该放弃编译时配置并采用基于文本的配置吗?是否有明显的层结构可以避免我没有看到的循环依赖的陷阱?