我应该如何设计一个类库以支持IoC，但不依赖于特定的容器？

Question

我正在开发一个类库，将在多个不同的Web应用程序中使用，甚至可能作为一个开源项目公开发布。 在几个点上，我想使用IoC，但是我不希望类库的消费者使用特定的实现方式。 有什么最佳方法来设计这个库，使它具有IoC的优势，但没有依赖于一个IoC框架？

具体来说，这个库包含了对各种服务接口具有依赖关系的ASP.NET MVC控制器。 我知道我可以创建一个IoCControllerFactory，但我不确定这是否是最佳方法，因为有些用户可能无法或不想在其应用程序中使用此功能只是为了获得我的库提供的功能。

- Daniel

---

我简直不敢相信我是第一个点赞这个问题的人！好问题。 - Ruben Bartelink

https://dev59.com/2HRB5IYBdhLWcg3w-8A9#1825667 - Ruben Bartelink

Answer 1

对于简单情况，可以在构造函数中传递属性。

对于更复杂的情况，请使用Ioc容器接口，提供默认实现，但使其足够简单，以便可以使用任何容器进行实现。

CommonServiceLocator 是这种类型的接口。

---

编辑：

我现在会推动另一种设计，这将使CommonServiceLocator无用，并且会使您的库用户的整体体验更好：

您选择具有所有所需功能的Ioc容器，将其作为内部ILMerge，以使您的库用户看不到它。用户不必知道库正在使用容器。

然后，您需要提供两个主要扩展点：

配置 - 提供自定义实现的依赖项的方法（例如Logger...） 工厂 - 如果您的库需要实例化用户对象，请提供一种指定工厂的方式，以便您的用户可以挂钩它。这样，他们就可以使用自己的容器来实例化和注入他们的对象。

我写了两篇关于这个设计的完整博客文章：

IOC Container, Go Hide

IOC Container, Go Hider (part 2)

- Think Before Coding

Answer 2

如果依赖项的数量相当少，您可以通过构造函数将它们传递进去。这样，您的消费者就完全可以选择如何构建您的对象。

属性/设置器或自定义初始化对象是其他可能性，并涵盖设计谱系中的其他领域。

- David Schmitt