我们在创建分层库时使用StructureMap作为我们的依赖注入(DI)框架。我们的目标是:有关可扩展性和可测试性的(分层)库中StructureMap的问题
- 让我们在开发和维护库的时候能够轻松地单元测试类(并使用模拟类而不是真正的依赖关系)。
- 很容易让图书馆用户:
- 通过异体实现一个接口他们和配置要使用的库的执行,而不是我们自己的自定义库的行为。
- 单元测试他们实现的类(这与我们内部的目标是一样的,但我们希望它也为图书馆用户完成)。
通过分层的图书馆,我们的意思是,我们正在建设两个DLL`s:
- 的核心库。它应该可以在任何.NET应用程序中使用,无论是Console应用程序还是MVC应用程序。
- WebForms库。它包含核心库,还提供WebForms控件,使WebForms用户的生活更轻松。
我们的问题:
我们应该在哪里调用代码映射混凝土类核心库接口?它没有单一的入口点,有许多类可能首先被实例化。
目前我们强制用户在进行任何其他库调用之前先致电
DependencyHandler.Init()
。有没有更好的方法,就像加载DLL后执行的一段代码一样,这样我们就不会强制用户编写一行锅炉代码?哪种方法让图书馆用户将接口实现更改为自己的类型?目前,用户可以通过
StructureMap.Configuration.DSL.Registry theRegistry = DependencyHandler.Instance().GetConfiguration()
检索注册表,然后通过例如theRegistry.For<IFoo>().Use<MyOwnFooImplementation>();
更改事情。使用XML会更好吗?如果是这样,我们应该在哪里放置XML?我们选择编程方法,因为Visual Studio将能够为用户提供一些帮助。如果使用上述中的当前方法,则库用户必须(至少现在)向StructureMap.DLL以及我们的DLL添加引用。我们是否可以通过使用XML进行依赖设置来消除用户的负担?
在我们应该使用的WebForms中是否有一个很好的中央位置,它可以解决问题 for WebForms library DLL?
您如何建议我们为生产和测试构建物件?
目前的想法是在必要的所有地方使用DI,以启用单元测试,我们和我们的用户需要它,并且允许用户通过提供自己的实现来更改库行为。
为了测试事情,我们和库用户将不得不创建模拟类来替换我们想要脱离的依赖关系。这个想法是,我们使用正常的配置,但覆盖我们想要模拟的类,而不是使用它们的正常实现。这是继续进行的好方法吗?