Дизайн библиотеки и 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...
}

Итак, вместо того, чтобы вводить X509HttpClientFactory для IHttpClientFactory , библиотека создает экземпляр для IX509HttpClientFactory. IHttpClientFactory по-прежнему «доступен» для инъекций.

Мой вопрос не предназначен для c flurl, это скорее общий вопрос для аналогичного сценария ios.

Это хорошо дизайн? Как вы справляетесь с такими случаями, когда у вас есть настраиваемые сторонние зависимости? Возможен ли сценарий нарушения CA1040.

Answer 1

Итак, вместо того, чтобы вводить X509HttpClientFactory для IHttpClientFactory, библиотека создает экземпляр для IX509HttpClientFactory.

Если я правильно вас понимаю, тогда да, я думаю, это путь к go. DI - это концепция уровня приложения, и, хотя мы привыкли использовать ее для создания экземпляров большинства вещей, она по-прежнему полностью соответствует new внутренним зависимостям библиотеки, чтобы эта библиотека была хорошо инкапсулирована. Я бы даже не стал раскрывать IX509HttpClientFactory публично, если бы в этом не было необходимости.