Говоря о зависимостях , можно использовать оба термина, иногда (опасно) взаимозаменяемо. React — это фреймворк или библиотека? Как насчет Bootstrap или Lodash ? В конце концов, оба являются « пакетами », верно?

Конечно, но они определенно не окажут такого же влияния на ваше приложение.

Библиотеки

Библиотека («bibliothèque» по-французски, но большинство французов говорят «librairie», что на самом деле означает «книжный магазин» по-французски, но соответствует английскому произношению «библиотека») — это набор функций общего назначения (например, underscore.js ) . или специализированные (например, moment.js ).

Вы вызываете библиотечные функции всякий раз, когда они вам нужны, как вы выбираете инструменты в наборе инструментов. Они не требуют каких-либо изменений в дизайне вашего программного обеспечения .

Собственные вызовы

Однако в качестве зависимости они требуют, чтобы вы вызывали их проприетарный API, тем самым «запирая» ваш код с ними (или даже, возможно, с их версией ), так что вызов библиотеки должен выглядеть примерно так:

Такая блокировка будет увеличиваться с увеличением количества вызовов, которые вы выполняете: чем больше вы вызываете библиотеку, тем больше ваш код зависит от нее (или от ее версии):

Единая точка зависимости

Однако, чтобы ограничить такую ​​зависимость, вы можете скрыть ее за оболочкой:

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

Однако, говоря о реализации, шаг за шагом, ваш код по-прежнему зависит от библиотеки.

Бизнес API

Надеюсь, как говорил покойный Дэвид Дж. Уиллер:

Все проблемы информатики могут быть решены на другом уровне косвенности .

Действительно, вы можете избежать такой зависимости, добавив интерфейс :

• вызывающие абоненты будут зависеть от этого объявления API;
• адаптер должен будет реализовать это (обратите внимание, что это также облегчит имитацию библиотек при тестировании).

Фреймворки

Фреймворки («quadriciels» на официальном французском языке, но все говорят «фреймворк») отличаются друг от друга, поскольку они предоставляют другой тип услуг: они предлагают вам управлять вещами вместо того, чтобы позволять вам придумывать, что делать.

Передача управления

Для этого они реализуют основу («фрейм») приложения и позволяют вам заполнить пробелы. Но эти пробелы остаются в определенных местах и ​​имеют определенную форму.

Что означает, что:

• приложение начинается с рамок : вы должны передать руль.
• поскольку фреймворк управляет приложением, вы больше не звоните: вместо этого фреймворк перезвонит вам , когда это будет необходимо.

Контракты

Конечно ничто не мешает вам вручную вызвать какой-то свой код, стороннюю библиотеку или даже какой-нибудь API фреймворка, но на свой страх и риск . Это может работать или не работать, как вы ожидаете. Фреймворки имеют правила , которым вы должны следовать, и, если вы их нарушите, фреймворк не будет нести ответственность за какой-либо сбой.

Обычно фреймворк позволяет вам писать компоненты , которые будут помещаться в свои контейнеры посредством реализации контракта :

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

Как видите, это гораздо более структурный выбор, чем библиотеки для разработки вашего приложения: все ваши компоненты становятся специфичными для этой среды. Он не будет ни переносимым (т.е. не понятым другим фреймворком), ни интероперабельным (т.е. компонент Angular вряд ли будет взаимодействовать с компонентом React).

Однако можно возразить, что шаблон адаптера можно использовать для ограничения зависимости от фреймворка, точно так же, как мы это сделали для ограничения зависимости от библиотек:

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

Тогда внутри фреймворков адаптеры компонентов были бы ненужными слоями.

Библиотеки фреймворка

Библиотеки также могут соответствовать фреймворкам. Вместо того, чтобы предоставлять API, они предоставляют реализации компонентов для данной среды.

По мере того, как фреймворки становились популярными, стал доступен ряд библиотек фреймворков. Однако большинство из них касаются виджетов: например, компоненты Material Design были перенесены с Android на веб-компоненты , Angular , React , Vue и даже фреймворки iOS .

Стандартные рамки

Любой может себе представить огромные затраты на перенос одной и той же библиотеки (и ее последующих версий) на каждый из этих фреймворков.

IBM разработала решение по этому поводу : вместо того, чтобы портировать систему Carbon Design на каждую из прошлых, текущих и будущих разрекламированных платформ, они вложили средства в порт на стандартной платформе веб-компонентов , которую можно использовать в любом контексте.

Так вот, не только это позволяет использовать свои компоненты из фреймворков:

Но те же компоненты можно использовать и в обычном приложении:

Заключение

Фреймворки и библиотеки — это очень разные сторонние варианты:

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