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

我正在开发一个类库,它将在许多不同的Web应用程序中使用,甚至可能作为开源项目提供.有几点我想使用IoC,但我不希望类库的使用者必须使用一个特定的实现.设计这个库的最佳方法是什么,以便它具有IoC的优点,但不依赖于一个IoC框架？

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

在构造函数中传递属性以用于简单方案.

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

CommonServiceLocator就是这种接口.

编辑:

我现在推出另一个设计会使CommonServiceLocator变得无用,并且会让你的图书馆用户的整体体验变得更好:

您选择具有内部库要求所需的所有功能的Ioc容器,并将其ILMerge为内部,以便您的库用户不会看到它.用户不必知道库正在使用容器.

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

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

IOC容器,Go Hide

IOC Container,Go Hider(第2部分)