Как работать с пакетами nuget с разными зависимостями? - PullRequest
Новая
       36

Как работать с пакетами nuget с разными зависимостями?

0 голосов
/ 08 марта 2020

Я поддерживаю несколько пакетов nuget, которые используют сервер JSON и / или SQL.

В настоящее время они зависят от Newtonsoft.Json и System.Data.SqlClient, но я получил запросы на поддержку System.Text.Json и Microsoft.Data.SqlClient. Обновление кода тривиально, но что мне делать с пакетами nuget?

  1. Выпускать новые основные версии существующих пакетов
  2. Создание новых пакетов

С новые основные версии, мне не нужно обновлять все зависимые пакеты, но обновления могут сбивать пользователей с толку (например, Newtonsoft.Json пользователи не должны обновлять основную версию).

Новые пакеты делают это более понятным, но я не знаю, как их назвать. Особенно, если пакет зависит от сервера JSON и SQL (то есть от 3 новых пакетов)

Я пытался найти, например, nuget.org, но ничего не нашел.

Есть ли рекомендации или лучшие практики для подобных ситуаций?

1 Ответ

1 голос
/ 09 марта 2020

Один из вариантов заключается в том, чтобы не иметь ни одной из этих зависимостей в самом пакете, а извлечь общее поведение интерфейса и позволить вызывающим сторонам внедрить свою собственную реализацию. Таким образом, потребители могут выбрать любую зависимость, которая им нравится.

Хорошим примером является интерфейс ILogger - библиотеки ведут журнал, используя интерфейс, и вызывающие абоненты могут выбрать для внедрения любую реализацию, которая им нравится (например, одну из Serilog или log4net).

Недостатком является то, что если не существует существующего интерфейса, который соответствует вашим потребностям, то вам нужно предоставить его (и, вероятно, его реализации, упакованный по одному для каждой зависимости, чтобы потребители могли смешивать и сопоставлять).

Это большие перемены, поэтому я бы подумал сделать это под новым именем пакета и пространством имен, а также отказаться от существующего пакета.

Использование зависимостей в имени пакета возможно, но вы получаете комбинаторный взрыв. Common.Logging использует этот подход, но также должен был включать в название номер версии deps, что еще больше усиливает взрыв (обсуждение того, почему здесь ).

Просто удар по основной версия звучит как кошмар, особенно если люди хотят выбрать зависимости в нижней версии.

...