Сервисы отлично подходят для обмена данными между несколькими компонентами. Они отлично подходят для хранения некоторого состояния, некоторых настроек конфигурации и даже консолидации вызовов API. Они точно могут многое. Почему бы не использовать их для всего?
В других постах я упоминал, что сервисы не так хороши для запуска ядра вашего приложения. В приложении Angular у вас, по сути, есть дерево компонентов, и эти компоненты могут полагаться на сервисы. А не наоборот. Помните, что в Интернете презентация находится в ваших шаблонах. Да, они превращаются в инструкции javascript, но вы должны строить с помощью компонентов и шаблонов. Позволь мне объяснить…
Сценарий
Допустим, вам нужно разработать интерфейс с возможностью отображения одной из двух пользовательских кнопок. Одна кнопка делает одно, другая — другое, но обе они выглядят одинаково.
В рецензировании я видел, как этот пример был сделан следующим образом. Сначала добавьте кнопку в свой шаблон, затем создайте фабричный сервис и внедрите его в свой класс компонента. Затем фабричная служба будет иметь две другие службы в своем списке зависимостей, по одной для каждой из предлагаемых функциональных возможностей, которым необходимо реализовать общий интерфейс и предоставить метод для выполнения работы. Затем ваш компонент вызывает фабрику, чтобы «разрешить» правильный сервис, а затем вызывает реализованный метод. Итак, давайте сложим это: 1 компонент, 1 фабрика, 2 службы и 1 интерфейс… все для двух кнопок.
Исправление
Помните, я говорил, что пользовательский интерфейс состоит из компонентов? Некоторые компоненты могут быть очень похожими и использовать общие шаблоны, а также могут расширять классы для совместного использования функций. Я предложил посмотреть на это с точки зрения компонентов, а не на то, как решить эту проблему с помощью сервисов.
Во-первых, мы можем создать два отдельных компонента. Самое интересное в этом то, что функциональность этих двух отдельных сервисов, упомянутых выше, может быть перенесена в эти компоненты. Затем в шаблоне родительского компонента просто условно покажите правильную кнопку, используя ngIf. Любая общая функциональность может быть в абстрактном классе, который могут расширять оба класса компонентов кнопок. Итак, вот: 3 компонента и, возможно, абстрактный класс.
Что в этом лучше, спросите вы? Ну, для начала, в этом посте я упомянул, что сервисы должны быть синглтонами. Теперь они не должны быть всегда, но идея в том, что если вы собираетесь иметь несколько возможных экземпляров чего-то, например кнопок, они должны быть в экземплярах компонентов. Кнопки в этом сценарии должны быть на карточках, которые отображаются в списке, где каждая карточка будет иметь одну из кнопок в зависимости от ее типа.
Следующим моментом является то, что фабричный шаблон разрешения сервисов, а не просто использование компонентов, добавляет дополнительные уровни сложности. Если вы посмотрите на это с точки зрения структуры компонентов, вы увидите, что это не что иное, как кнопки, которые имеют разную функциональность в зависимости от их взаимодействия. Эта функциональность может быть самодостаточной в пределах их классов компонентов, в чем и заключается весь смысл компонентов.
Конец?
Я за то, чтобы все было просто. Каждый раз, когда я вижу эту длинную цепочку ненужных сервисов и фабрик, сервисов мостов и адаптеров, я начинаю сходить с ума. У кого-то явно слишком много времени, и он предпочел бы добавить больше строк кода, чем сделать свои реализации простыми для понимания другими. И это то, что меня больше всего достает. Даже если вы единственный разработчик, просматривающий ваш код, сделайте его простым для понимания и выполнения. Будь проще.
Компонентная архитектура не должна быть слишком сложной. Если вы представляете все как компонент и строите свои компоненты с другими компонентами, в конечном итоге у вас есть приложение. Эта идея характерна не только для Angular. Веб-компоненты, React, Vue.js и другие предназначены для создания сложных вещей из более мелких и изолированных вещей.
Начать создавать функции вокруг сервисов очень легко становится проблематично. Сервисы можно использовать повторно, но не так, как компоненты. Думайте о компонентах как о штампе, и каждый раз, когда вам нужен новый экземпляр, вы штампуете новый. Услуги больше похожи на стиральные и сушильные машины в прачечной. Вы не можете построить что-то с ними, и каждый может их использовать. Поэтому не используйте их для всего и научитесь полагаться на свои шаблоны и компоненты.
