我应该如何设计一个类库来允许IOC,但不依赖于特定的容器

在简单方案的构造函数中传递属性。

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

CommonServiceLocator 就是这样的接口。

编辑:

现在我将推出另一种设计,使CommonServiceLocator变得无用,并使您的库用户的总体体验更好:

您选择的IOC容器具有满足内部库需求所需的所有功能,并将其合并为内部容器,以便您的库用户看不到它。 用户不必知道库使用的是容器。

然后,您必须提供两个主要扩展点: 配置-提供依赖项自定义实现的方法(例如记录器…) 工厂-如果您的库需要实例化用户的对象,请提供一种指定工厂的方法,以便您的用户能够钩住它。这样他们就可以使用自己的容器来实例化和注入他们的对象。

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

IOC Container, Go Hide

IOC Container, Go Hider (part 2)

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

属性/设置器或自定义初始化对象是可选的可能性,涵盖了设计范围中的其他领域。