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

Question

[Андрей]

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

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

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

Насколько это хорошая практика?

Comments

[Антон Швец]

Хорошая практика это не придумывать свои велосипеды и взять Ангуляр.

Answer 1

[ned4ded]

Добрый день.

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

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

The core library is focused on the view layer only

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

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

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

Comments

[Андрей]

Я согласен касательно велосипедов, и всё больше склоняюсь в пользу того, чтобы использовать фреймворк и его официальные плагины по назначению. Но тут еще нужно удовлетворить требования компании, где главная загвоздка в том, чтобы в будущем можно было быстро перейти на новую технологию, без переписывания с нуля, как приходиться это делать сейчас. Это требование в первую очередь связано с тем, что скоро будет Vue 3, который "еще быстрее и еще лучше", но есть опасение, что он без обратной совместимости с Vue 2.

[ned4ded]

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

Да и я сильно сомневаюсь, что разница между vue2 и vue3 будет настолько большая, насколько была разница между angularjs и angular2. Сейчас вью намного проще в освоении и его core функционал хорошо настроен, нет нужды в том, чтоб его переписывали с нуля.

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

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

Answer 2

[d1mmmk]

Совершенно правильная идея. Дело даже не в том что можно абстрагироваться от шаблона представления, а в том что это даст возможность переиспользовать контролеры/сервисы в рамках приложения, избавиться от необходимости использования сторонних библиотек хранения состояния, сделать кешированние данных через static методы и централизованно обрабатывать запросы к API.

Answer 3

[vanyamba-electronics]

Для ядра это слишком много логики. Нужно разделить задачи, которые выполняет приложение, на части. Например, в одном приложении вы работаете с данными в базе, в другом приложении работаете с отчётами.
Как говорят у нас на флоте - Keep it simple.

Answer 4

[nvdfxx]

Идея здравая с виду, но зачем? У вас руководство на гитхабе сидит и каждый 5 минут f5 нажимает, в ожидании выхода нового релиза какого-нибудь фреймворка? Основные фреймворки вроде как достаточно стабильны, под них стомильенов библиотек, куча документации, ну не будет, допустим, во вью3 обратной совместимости, и что? Он не будет решать каких-то суперспециализированных задач, с которыми не справятся другие фреймворки/версии того-же фреймворка. Закончите писать на вью3, выйдет реакт 20, а за ним ангуляр 35. Так зачем эта гонка?

Answer 5

[EVG]

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