@AndrewRusinas

Будет ли хорошей практикой такая структура приложения на Vue?

Недавно на тостере я опубликовал вопрос архитектуры приложения для ERP. Там было бурное обсуждение, но какого-то конкретного решения я не увидел.

Но в ходе размышлений пришла следующая мысль. Сразу оговорюсь, что она, вероятнее всего, несколько противоречит компонентному подходу Vue.

Суть в том, чтобы оставить на vue исключительно презентационную логику. Всю бизнес-логику вынести в отдельные контроллеры, создав таким образом "ядро" приложения, которое будет обрабатывать все данные, общаться с сервером, и отдавать готовые данные, которые нужно будет только отрендерить. Это (в идеале) позволит немного абстрагироваться от рамок конкретного фреймворка, в случае, если возникнет необходимость перейти на другой.

Насколько это хорошая практика?
  • Вопрос задан
  • 1782 просмотра
Пригласить эксперта
Ответы на вопрос 5
@ned4ded
Верстка, Фронтенд
Добрый день.

Не совсем понятно, что в данном контексте вы подразумеваете под контроллерами и бизнес-логикой.

Сам по себе vue не общается с сервером и кейс его использования связан исключительно с отображением. О чем, собственно, и написано в их официальном гайде:

The core library is focused on the view layer only


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

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

Как по мне, лучшее решение - это использовать дополнительный плагин для вью - стор (vuex). В этом модуле вы сможете хранить запросы к серверу, логику обработки данных и проч. приблуды, связанные с бизнес-логикой, не изобретая велосипед.
Ответ написан
@d1mmmk
Совершенно правильная идея. Дело даже не в том что можно абстрагироваться от шаблона представления, а в том что это даст возможность переиспользовать контролеры/сервисы в рамках приложения, избавиться от необходимости использования сторонних библиотек хранения состояния, сделать кешированние данных через static методы и централизованно обрабатывать запросы к API.
Ответ написан
Комментировать
@vanyamba-electronics
Для ядра это слишком много логики. Нужно разделить задачи, которые выполняет приложение, на части. Например, в одном приложении вы работаете с данными в базе, в другом приложении работаете с отчётами.
Как говорят у нас на флоте - Keep it simple.
Ответ написан
Комментировать
@nvdfxx
Senior Pomidor developer
Идея здравая с виду, но зачем? У вас руководство на гитхабе сидит и каждый 5 минут f5 нажимает, в ожидании выхода нового релиза какого-нибудь фреймворка? Основные фреймворки вроде как достаточно стабильны, под них стомильенов библиотек, куча документации, ну не будет, допустим, во вью3 обратной совместимости, и что? Он не будет решать каких-то суперспециализированных задач, с которыми не справятся другие фреймворки/версии того-же фреймворка. Закончите писать на вью3, выйдет реакт 20, а за ним ангуляр 35. Так зачем эта гонка?
Ответ написан
Комментировать
@f_ban
Так ведь весьма здравая и зрелая с архитектурной точки зрения мысль. Фреймворк чего-либо там - всего лишь незначительная деталь реализации. Вся ценность системе - ее бизнесправила, юз-кейсы и их чистота реализации. Действительно, реализуя спа, важно сделать границу между слоем, работающим с бизнес-правилами, и слоем, просто отрисовывающим Стейт, или вьюв-модель. В итоге, каждая часть будет заниматься своим делов, и как бонус, легко за аб-тестить хоть все фронт-фремворки одновременно.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы