我正在尝试使用 Caliburn Micro 和 nHibernate 为新的 LOB MVVM 项目设计架构,现在正在研究 DI 和 IOC。
许多引导 Caliburn Micro 的示例使用 MEF 作为 DI\IOC 机制。
我正在苦苦挣扎的是,MEF 似乎相当受欢迎,但 Mef [Imports] 注释的想法在我看来就像是另一种服务定位器?
我是否遗漏了有关 MEF 的某些内容,几乎所有我见过的示例都没有正确使用它,或者我完全不了解它的使用方式,从而绕过了整个服务定位器问题?
我正在尝试使用 Caliburn Micro 和 nHibernate 为新的 LOB MVVM 项目设计架构,现在正在研究 DI 和 IOC。
许多引导 Caliburn Micro 的示例使用 MEF 作为 DI\IOC 机制。
我正在苦苦挣扎的是,MEF 似乎相当受欢迎,但 Mef [Imports] 注释的想法在我看来就像是另一种服务定位器?
我是否遗漏了有关 MEF 的某些内容,几乎所有我见过的示例都没有正确使用它,或者我完全不了解它的使用方式,从而绕过了整个服务定位器问题?
MEF 本身不是服务定位器。它可以用来实现服务定位器( Silverlight 版本中的CompositionInitializer实际上是 MEF 中内置的服务定位器),但它也可以直接进行依赖注入。
虽然这些属性可能对您有“味道”,但它们本身并不会导致它成为服务定位器,因为您可以[ImportingConstructor]
在创建时使用它来注入数据。
请注意,这些属性实际上并不是使用 MEF 的唯一方法——它也可以通过直接注册或基于约定的注册来工作(CodePlex drop 和 .NET 4.5 支持)。
我想如果您只new
使用具有属性导入的部分并尝试使用它们,那么您可能会遇到此处描述的一些相同问题:Service Locator is an Anti-Pattern
但在实践中,您从容器中获取零件,如果您在[Import]
没有附加allowDefault
属性的情况下使用,那么该零件是必需的,如果您要求进行导入的零件,容器会炸毁您。它会在运行时爆炸,是的,但与磨房服务定位器的运行不同,使用测试框架对 MEF 容器进行静态分析相当简单。我已经在这里和这里写过几次了。
在实践中这对我来说不是问题,原因有几个: