Как портировать java приложение под веб?

Question

[harmshark]

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

Какой фреймворк можно было бы использовать?

Comments

[MaxLich]

Не уверен, что вообще есть способ автоматически это переконвертировать, и тем более - малоболезненный. Кроме того, если у вас приложение не монолит, и логика отделена от отображение, то это будет не таким уж сверхсложным - просто надо будет другое отображение запрограммировать. А вот если хренов монолит... тогда Вас ждёт долгая и весёлая работа на несколько тысяч дней и ночей! :-)

[MaxLich]

А так, самый популярный из последних джавовских библиотек для веб-фронта - это ZK framework. Но вообще, фронт чаще всего пишется на джаваскрипте (естественно вместе с хтмл и ксс). И для этого в джаваскрипте есть отдельные фреймворки.
Кроме того, для веба в джаве сейчас популярен Spring MVC, например.

[Fedor]

На чем написан сервер? Взаимодействие через API?

[MaxLich]

Согласен с Fedor, нужно больше информации по текущей системе.

Answer 1

[Алексей Черемисин]

Ну, что же. Фреймворк берите на свой вкус, jooby.org, sparkjava или springboot. Я первым прифанател.
Что касается вот всего вот этого Также имеются всякие компоненты типа интерактивного календаря и планировщика. - то рекомендую, настоятельно, это делать на vuejs или react. И это все у вас будет в javascript, без всякой java. А java будет только отдавать данные по REST/json.
Но, блин, как уже заметил MaxLich , это не портирование, а написание с нуля!

Comments

[MaxLich]

Но если у него не монолит, а тот же MVC, то будет не так сложно перейти на веб. А если ещё и пересылка даннных идёт по REST/JSON, то это ещё больше облегчить работу по переходу на веб.

[Алексей Черемисин]

MaxLich, Ну, да кто его знает... Обычно, даже тот-же самый MVC для GUI, совсем не MVC для web. А если через REST, то уж больше к JS вопрос, чем к яве.

[MaxLich]

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

[Алексей Черемисин]

MaxLich, Вот-вот, я про это же самое. Честно говоря, сколько GUI не встречал, почти все пользуют коллбеки прямо в контроллере. Оно там гораздо удобнее, ни тебе сессий, ни тебе реквестов. И вот это вот переносить - данунах :-) Как раз намедни с подобным гуем имел дело, нужно было сделать чекбокс выбранный и задисейбленый (серенький и с галочкой). Вместо 15 минут - 2 дня через классы просирался... :-D Гуй делает только одно, по куче параметров и лигики генерирует параметры коммандной строки и запускает процесс! 72, мать его, класса, строк по 500 каждый!

[Зелимхан Бельтоев]

MaxLich, даже если MVC, задача не легкая будет, так как там, судя по описанию, на клиенте ещё нужно работать с железом, что не так уж и просто будет сделать.

[MaxLich]

Зелимхан Бельтоев, На клиенте!? С Железом!? Вы о чём? О_о Толстого клиента захотели? Всё должно выполняться на сервере!
Хотя если это внутреннее корпоративное веб-приложение, и нужно снимать характеристики компьютера, за которым работает пользователь, то тогда да, понятно. Но это будет ещё то веселье. И это уже не работа джава-программиста.