有关可扩展性和可测试性的（分层）库中StructureMap的问题

Question

我们在创建分层库时使用StructureMap作为我们的依赖注入（DI）框架。我们的目标是：

• 让我们在开发和维护库的时候能够轻松地单元测试类（并使用模拟类而不是真正的依赖关系）。
• 很容易让图书馆用户：
  • 通过异体实现一个接口他们和配置要使用的库的执行，而不是我们自己的自定义库的行为。
  • 单元测试他们实现的类（这与我们内部的目标是一样的，但我们希望它也为图书馆用户完成）。

通过分层的图书馆，我们的意思是，我们正在建设两个DLL`s：

1. 的核心库。它应该可以在任何.NET应用程序中使用，无论是Console应用程序还是MVC应用程序。
2. WebForms库。它包含核心库，还提供WebForms控件，使WebForms用户的生活更轻松。

我们的问题：

1. 我们应该在哪里调用代码映射混凝土类核心库接口？它没有单一的入口点，有许多类可能首先被实例化。

   目前我们强制用户在进行任何其他库调用之前先致电DependencyHandler.Init()。有没有更好的方法，就像加载DLL后执行的一段代码一样，这样我们就不会强制用户编写一行锅炉代码？

2. 哪种方法让图书馆用户将接口实现更改为自己的类型？目前，用户可以通过StructureMap.Configuration.DSL.Registry theRegistry = DependencyHandler.Instance().GetConfiguration()检索注册表，然后通过例如theRegistry.For<IFoo>().Use<MyOwnFooImplementation>();更改事情。使用XML会更好吗？如果是这样，我们应该在哪里放置XML？我们选择编程方法，因为Visual Studio将能够为用户提供一些帮助。

3. 如果使用上述中的当前方法，则库用户必须（至少现在）向StructureMap.DLL以及我们的DLL添加引用。我们是否可以通过使用XML进行依赖设置来消除用户的负担？

4. 在我们应该使用的WebForms中是否有一个很好的中央位置，它可以解决问题 for WebForms library DLL？

5. 您如何建议我们为生产和测试构建物件？

   目前的想法是在必要的所有地方使用DI，以启用单元测试，我们和我们的用户需要它，并且允许用户通过提供自己的实现来更改库行为。

   为了测试事情，我们和库用户将不得不创建模拟类来替换我们想要脱离的依赖关系。这个想法是，我们使用正常的配置，但覆盖我们想要模拟的类，而不是使用它们的正常实现。这是继续进行的好方法吗？

Answer 1

需要注意的是，为了提供从别人可以隔离他们的代码，你需要确保他们能够依赖于抽象，而不是具体实现的API是很重要的。也就是说，只要你公开的那些“做东西”的类实现了一个接口（通常是最好的），就继承了一个定义接口的抽象类，或者让所有的公共成员都是虚拟的（通常是最糟糕的），我您的API的消费者能够将我的代码与具体实现隔离开来。 换句话说，你自己使用IoC容器并不是提供可测试API的关键。但是让你的类非静态的和抽象的实现是。尽管如此，使用容器还有很多其他的好处。例如，你可能有一个更容易的时间在你自己的API :)

1. 没有单一的入口点测试的各种类，但用你我的API将实例化一个或几个类吧？每个类都可以有构造函数，这些构造函数要求客户提供该类所依赖的抽象的具体实现。为避免强制客户端指定要使用的实现，您还可以提供使用默认实现的无参数构造函数。

2. 这取决于，但是从你的方法到简单的DSL将API连接到配置文件都可以。一般来说，正如我之前所说的，客户端可能不会对改变你的类所依赖的实现感兴趣，只要他们自己可以将自己的代码与“顶级”类隔离开来。

3. 应用程序开始可能是一个很好的地方。 Web Forms库可以是HttpModule，或者您可以提供默认的引导捆绑并指示客户端在global.asax中的应用程序启动事件中进行所需的任何更改。

4. 听起来不错。就像我之前说的，我认为最重要的是你的类和它们的方法不是静态的（最好不是单例），并且它们的接口是以抽象的方式定义的，因此人们可以提供其他具体实现来测试。

我可能误解了一些东西，但我希望我的回答可以帮助至少有一点:)