简短的问题是:
给定一个图书馆warrants当应用程序使用该库时,在给定应用程序的情况下,将特定的 IOC 容器用于其内部warrants使用 IOC 容器来连接其依赖项,如果两个容器不同,它们如何才能很好地协同工作?
场景是,应用程序定义了依赖于库中的类型的类。因此,当应用程序容器尝试构建这样的类时,它需要知道如何解析库中的类型。
这是一个冗长的问题:
这个问题似乎之前已经以不同的形式被问过,但我似乎找不到我需要的答案,所以我将用一个假设的_over_simplified_具体例子来尝试一下。
我们希望编写一个用于日志记录的库,用户可以将其作为包包含在他们的解决方案中,以获得开箱即用的日志记录功能。
该库公开的公共接口是..
public interface ILogger {}
public interface ITarget {}
具体实现是
internal class Logger: ILogger { public Logger(ITarget target) {}}
internal class FileTarget : ITarget {}
要求是用户是否包含我们的包并定义一个具有 type 属性的类ILogger
或者有一个类型为 ctor 的参数ILogger
然后我们的库负责将该接口的具体实现注入到用户定义的类中。默认情况下,注入的记录器将转到文件系统进行日志记录,因为默认实现ITarget
注入到ILogger
实施是一个FileTarget
由我们的图书馆提供。
如果用户决定编写一个类来实现ITarget
接口然后我们的库将使用它来注入Logger
类并且不使用其默认值FileTarget
执行。
所以我想证明的是,它们是双向依赖关系。
我们的库依赖于用户的程序集,因为它需要扫描用户的程序集以加载任何扩展点(即ITarget
实现)并在任何默认实现之前将它们注入到它自己的对象中。
用户的程序集取决于库,因为如果用户选择使用ILogger
接口作为依赖项,那么该用户对象应该获得对我们的库在运行时提供的该接口的具体引用。
简单的解决方案是,如果用户和我们的库都使用相同的 IOC 容器,那么问题就解决了。但这是一个强有力的假设。我想做的是
- 将 IOC 容器与最能满足库要求的库一起使用,在我的例子中是 Ninject。
- 在运行时,以某种方式提供一种机制,让用户通过某些 API 调用我的库,这将确保 Ninject 被启动并扫描用户的程序集,并考虑所有扩展点来连接所有内容。
到目前为止一切顺利,完全可以实现,但棘手的部分来了。
- 如果用户也在使用 Ninject,那么问题会自动解决,因为 Ninject 已经知道如何解析我们库中的接口。但是,如果用户决定使用他/她选择的 IOC 容器怎么办?
我几乎想用这样的接口在库中定义某种子容器功能
public interface IDependencyResolvingModule { T Get<T>(); []T GetAll<T>(); }
并提供一个使用我们库选择的容器(即 Ninect)的实现来解析上面定义的两个方法中请求的类型。
我希望用户的 IOC 容器具有一些功能,如果它无法解析依赖项(即ILogger
),它应该挂入IDependencyResolvingModule
实现并请求依赖。
这样我们的库就可以使用它选择的 IOC 容器,并且用户的代码可以解决其 IOC 容器不知道的依赖关系。如果 IOC 容器提供了一些功能来注册任何对象的单例实例,那么这个解决方案不会起作用吗?IDependencyResolverModules
在执行程序集目录中的程序集中找到,当它们无法解析类型时,询问任何单例模块吗?
但除非有一个解决方案需要所有其他 IOC 容器都能容纳,否则还能如何解决这个问题呢?因此,几行中的问题是,当第三方程序集选择将 IOC 容器用于其内部时,有什么简单的解决方案,使得该库可以简单地为位于外部的 IOC 容器提供一种机制来挂钩并解决依赖关系住在图书馆里的。