具有第 3 方依赖项的库设计和 DI

Question

我正在编写一个供内部使用的库。 这个库的目的是抽象出对一些内部 REST API 的调用。 在后台，我使用 Flurl 来提出请求。 该库还提供了设置 DI（Core Web）以轻松将所有内容连接在一起的扩展方法（ services.AddXYIntegration() ）。 在 flurl 的情况下，我的库提供了DefaultHttpClientFactory的实现（从IHttpClientFactory继承）=> X509ClientFactory 。 为了避免使用我的库的应用程序的冲突或覆盖 DI，这些库可能还使用 Flurl 处理 https 请求并希望为IHttpClientFactory提供自定义实现，我创建了一个空接口，只是为了“标记”我的库实现并在 DI 接线中使用它。

一点点代码：

public interface IX509HttpClientFactory : IHttpClientFactory 
{
    // empty interface, violates CA1040
}

public class X509HttpClientFactory : DefaultHttpClientFactory /* inherits from IHttpClientFactory */, IX509HttpClientFactory
{
    // Implementation details...
}

因此，库不是为IHttpClientFactory注入X509HttpClientFactory ，而是为IX509HttpClientFactory创建实例。 IHttpClientFactory仍然“可用于”注入。

我的问题不是针对 flurl 的，而是针对类似情况的一般性问题。

这是一个好的设计吗？ 您如何处理具有可配置的 3rd 方依赖项的这种情况？ 违反 CA1040 是否可行。

Answer 1

因此，库不是为IHttpClientFactory注入X509HttpClientFactory ，而是为IX509HttpClientFactory创建实例。

如果我对您的理解正确，那么是的，我认为这是通往 go 的方式。 DI 是一个应用程序级别的概念，尽管我们习惯于使用它来实例化大多数事物，但它仍然完全适合在库内部new依赖项以保持该库的良好封装。 我什至不会公开公开IX509HttpClientFactory除非有我没有看到的需要。