ДЛЯ КОГО ЭТО МОЖЕТ ЗАНИМАТЬСЯ
мы нанимаем сотрудников в Cobiro, поэтому, если вы хотите работать с продвинутыми угловыми темами, которые я упоминаю в своих статьях, подайте заявку по адресу: https://cobiro.bamboohr.com/jobs/
Классический интерфейс CRUD
Есть проект с нуля, девелопер только вы. Макет понятен и прост. Каждая страница имеет свои собственные данные, и страницы мало связаны друг с другом, кроме общей навигации и нижнего колонтитула ...
Вот как это обычно начинается: если вы сомневаетесь в связи между интеллектуальным компонентом и компонентом презентации или в том, как получить данные из бэкэнда, вы просто зайдите на angular.io и следите за Туром героев, и через секунду все готово. :) пока нет Stackoverlow ...
Большинство приложений могут хорошо использовать следующую архитектуру:
Эта архитектура работает лучше всего, если все, что вам нужно сделать, - это вызывать разные конечные точки серверной части для каждой страницы, и у вас нет особых зависимостей между страницами.
Однако эта модель не будет масштабироваться, если вы хотите уменьшить взаимодействие с серверной частью. Вы также можете начать страдать, когда на каждую страницу нужно будет внедрить несколько сервисов, и у вас быстро возникнет проблема класса бога. Управление состоянием и обмен данными между компонентами также станет обременительным. Конечно, вы можете захотеть сохранить свое состояние в Smart Component или в другом сервисе. Но, на мой взгляд, это создает спагетти-код.
Преимущества пользовательского интерфейса на основе задач
Пользовательский интерфейс на основе задач - это архитектурный шаблон, который отделяет ваш уровень пользовательского интерфейса (интеллектуальные компоненты) от уровня приложения (ваши службы / состояния / и т. Д.). Это делается путем введения крошечных сервисов приложений, таких как хранилище или командная шина, чтобы вы могли отправлять DTO-подобные объекты (команды / действия / события) из ваших компонентов в сервисы уровня приложения.
Использование пользовательского интерфейса на основе задач дает множество преимуществ. Вы можете погуглить и получить много вдохновения :) Я просто выделю самое важное для меня:
- Тестируемость: это легко протестировать, потому что я могу сосредоточиться на написании приемочных тестов и не зависеть от изменений в пользовательском интерфейсе. Еще одно преимущество заключается в том, что имитировать легко, поэтому я могу имитировать уровень приложения при тестировании интеллектуальных компонентов.
- Ремонтопригодность: поскольку я отключен от уровня пользовательского интерфейса, любые изменения в нем не влияют на код моего приложения. Кроме того, мои интеллектуальные компоненты не страдают от нескольких проблем с зависимостями, я просто могу изменить место хранения данных и изменить свою модель домена, не затрагивая мои интеллектуальные компоненты.
- Возможность многократного использования: команды диспетчеризации просты, и все интеллектуальные компоненты могут это делать. Поэтому, если вы хотите добавить простой виджет, который отправлял бы действие в части вашего состояния, это очень просто и не требует дополнительных зависимостей.
Государственная реализация
Наиболее распространенная реализация UI на основе задач - использование системы управления магазином. Служба приложения, которая позволяет взаимодействовать с приложением, - это само хранилище, которое имеет метод отправки, а затем будет использовать состояние или уменьшать его часть.
Вот его упрощенный обзор:
Эта архитектура довольно хороша, с ней можно далеко уйти. В общем, любой проект среднего размера успешно реализует этот шаблон с множеством преимуществ.
Однако в приложениях корпоративного уровня ваши состояния могут стать довольно большими (500–1000 строк кода), что сильно повлияет на вашу ремонтопригодность. Кроме того, если вы не будете осторожны, вы начнете делать слишком много вещей в классе состояния (например, логику приложения или домена), и тогда это будет трудно читать новым разработчикам.
Было бы нецелесообразно создавать собственный магазин, потому что есть несколько хороших готовых программ, которые вы можете использовать, однако это свяжет вас со своим собственным способом ведения дел. Что может быть плохо, если вы хотите следовать чистой архитектуре и независимому от фреймворка подходу (который я настоятельно рекомендую).
Я лично считаю, что Store и State фактически нарушают пару правил, которым я следую, например: разделение командных запросов, принцип единой ответственности.
Таким образом, хотя системы управления магазином - неплохие инструменты для средних приложений, их быстро становится трудно поддерживать. Я считаю, что есть способ получше, способ, который не будет стоить вам больших усилий, и вы можете получить чистый код и больше преимуществ.
Командная шина
Эта архитектура должна быть вам знакома. Командная шина - это служба приложения, которая, как и магазин, позволяет отправлять команды и является связующим звеном между пользовательским интерфейсом (интеллектуальный компонент) и приложением (обработчик команд).
Архитектура имеет 3 основных класса:
- Команда - это простая неизменяемая структура данных, которая содержит информацию, необходимую для управления состоянием в приложении. Нередко класс Command содержит пустую полезную нагрузку.
- Обработчик команд - это класс обслуживания на уровне приложения, который знает, что делать, когда клиент отправляет команду. Это очень тонкий слой, который должен решать проблемы приложения (постоянство, связь, безопасность и т. Д.). Метод handle возвращает void и может вызываться асинхронно.
- Командная шина - это просто система обмена сообщениями, которая знает, какая команда связана с каким обработчиком команд. Поэтому, когда команда отправляется на командную шину, она вызывает метод handle в обработчике команд.
Это похоже на магазин, не так ли? ну, эта модель масштабируется намного лучше, легче найти обработчик, который запускается для конкретной команды и который намного проще поддерживать. Кроме того, поскольку вы разделяете приложение на множество небольших обработчиков (в отличие от класса бога, такого как State), вы придерживаетесь принципа единой ответственности.
Возникает вопрос: Если обработчик команд очень тонкий, куда девается моя логика состояния?
ну ответ: Это зависит :)
Именно здесь проявляется сила командной шины, вам не нужно использовать какую-либо конкретную структуру, библиотеку или шаблон проектирования. Вы можете просто выбрать :) вы уже отключены от своего уровня пользовательского интерфейса, так что вы получаете преимущество. Вы не привязаны к конкретной системе управления состоянием, поэтому можете легко реорганизовать и поддерживать свой код.
Но ладно, я уверен, вы все еще хотите знать, каковы наиболее распространенные реализации обработчика команд, не так ли?
Самый простой - «Сервис» - да, такой же, как и в первом шаблоне выше :)
Более продвинутым является: Domain Driven Design - где вы можете указывать на свои доменные службы или агрегаты и управлять своим состоянием там с помощью технологии сохраняемости по вашему выбору.
Еще более продвинутым является: Разделение ответственности за запросы команд - это мой любимый шаблон, который мы используем в нашей компании. Однако вы должны использовать его с осторожностью, это довольно сложно и не подходит для любого приложения. Сначала убедитесь, что вы не можете использовать что-либо из вышеперечисленного, а затем переходите к нему.
Я не буду подробно объяснять, как это работает на самом деле, это будет в следующих статьях.
Но… думаю, не повредит, если я брошу в вас крохотную биграмму :)
Примеры обработчиков команд
Я сделал несколько видеороликов, демонстрирующих реализацию CommandBus и шаблона, так что вы, возможно, захотите взглянуть :)
Вся серия видео начинается здесь:
Резюме
Итак, после State есть жизнь :), и вы не привязаны к не обслуживаемому коду внутри огромных классов состояний. Выше представлены более продвинутые и более масштабируемые подходы.
Независимо от того, какой архитектурный шаблон вы используете, убедитесь, что ваше приложение отключено от пользовательского интерфейса с любой формой пользовательского интерфейса на основе задач.
Надеюсь, вам понравились эти статьи, следите за новыми интересными статьями.
