Нужен совет в проектировании приложения

Добрый день. Много лет программировал в delphi + СУБД (firebird, oracle). Сейчас осваиваю java (базовый курс пройден).
Для более быстрого осваивания решил начать уже писать что-то конкретное на Java. В качестве разрабатываемого ПО решил взять и переписать (частично) один из проектов разрабатываемый ранее на Delphi, работающий с БД под управлением СУБД Firebird (ср. по мощности субд). Посоветуйте этапы разработки и инструменты.
На Delphi в упрощенном виде выглядело так:
1. Проектировали БД: таблицы, хранимые процедуры и т.п. (по мере развития проекта БД естественно расширялась). Проектирование делалось на живом SQL, с использованием IBExpert (удобная среда, позволяющая быстро конструировать метаданные БД).
2. Далее на Delphi писался некий слой ORM - иерархия классов, позволяющие представить таблицы БД, связи между ними в виде объектов предметной области. Также осуществлять загрузку данных из БД, сохранения данных в БД.
3. Далее писался что-то типа слоя бизнес логики: как правило он делался через пачку новых классов и так называемых датамодулей. Здесь уже конкретно подготавливались данные, которые будут выводится в конкретных окошках (формах) с таблицами (гридами), кнопками и т.п. (интерфейсное окно пользователя).
4. Создавались в том же Delphi интерфейсные окна с кнопками, гридами (таблицами) и т.п., который для единого стиля программы наследовались друг от друга и конкретная реализация уже затачивалась под конкретный справочник, редактор и т.п. Эти окна стыковались с нашими датамодулями, а те в свою очередь с классами ORM.

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

Java EE предполагает разработку серверных приложений, без интерфейсных окон. Если речь именно о ней -- графическое приложение можно разработать отдельно и связать клиент-серверной архитектурой. Если делать монолитное -- может потребоваться "велосипедить" с бизнес-логикой.

"Эталонной" реализацией стандарта Java EE API считается серверная платформа Glassfish (https://glassfish.java.net/), разработываемая в Sun/Oracle вместе со стандартом и включающая в себя отдельные модули. Так называемая Java EE SDK -- фактически, тот же самый Glassfish + примеры. Если цель изучить Java EE для карьеры, а не повторить Delphi-приложение -- стоит почитать официальную документацию http://docs.oracle.com/javaee/7/index.html

Проектирование надо начинать точно так же с БД. Альтернативой может быть автогенерация БД по ORM-классам, но, ИМХО, не лучший метод.
ORM в контексте Java EE API называется Java Percistence API (JPA). Основные реализации: EclipseLink (входит в Glassfish по умолчанию) и Hibernate (вроде, проще интегрируется в десктопные приложения и имеет больше дополнительных функций).

EE-модули под бизнес-логику называются Enterprice Java Beans (EJB). Насколько я знаю, этот термин имеет смысл только в контексте серверной платформы.
Для обращения к ним снаружи можно использовать Web-сервисы (для протокола SOAP -- Jax-WS, он же Grizzly, для протокола RESTful -- и Jax-RS, он же Jersey). Так же можно оснастить EJB сетевым интерфейсом и обращаться к нему напрямую.

Для GUI актуальны JavaFX и Swing. Я давно не писал GUI-приложений на Java, деталей не знаю. Но, как минимум, оно будет отдельно от EE-приложения (если его ипользовать). Соответственно, можно написать серверное приложение на Java EE и поместить побольше логики туда, а графическое подключать по понравившемуся интерфейсу (мы используем преимущественно SOAP). Можно написать монолитное приложение без сервера (если хочется с ORM -- использовать Hibernate), но как в таком случае "фреймворкать" логику не подскажу.

Добавлено 23.02.15, 16:58
Кстати, насчёт выбора между клиент-серверным и монолитным графическим приложением. Если база данных не стоит на одном компьютере (или, по крайней мере, в одной защищённой сети) с этим приложением -- сервер (сама БД) будет по-любому, а передавать между клиентом и сервером команды Web-интерфейса с авторизацией и, желательно, по HTTPS всяко лучше, чем голые SQL-запросы: и безопаснее, и трафика меньше.

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

Спасибо за ответ.

Цитата kopilov @ 23.02.15, 16:38

Можно написать монолитное приложение без сервера (если хочется с ORM -- использовать Hibernate), но как в таком случае "фреймворкать" логику не подскажу.

Нет, монолитное не нужно. Как раз-то хотелось бы разделить приложение на слои.
1. На сколько я понял БД проектируем ручками с помощью SQL (какую бы СУБД посоветовали под Java - альтернатива Firebird).
2. ORM делаем с помощью Hybernate
3. Бизнес-логику через Springa или EJB (кстати, что лучше и востребованнее)
4. Интерфейс делаем через JSF или Swing (опять же, что что лучше и востребованнее. Что-нибудб знаете об ADF фреймворке -технологию от оракла. Мол типа схожа концепция с delphi, DataSet подцепляется к DataSource, а он в свою очередь к гридушке DBGrid)

Также я имел ввиду, что слой пользовательского интерфейса хотел бы заделать не под desktop, а под web, т.е. с возможность работать с программой через браузер.

Цитата kopilov @ 23.02.15, 16:38

Если цель изучить Java EE для карьеры, а не повторить Delphi-приложени

Конечная цель перейти с Delphi на Java в основном под Enterprice-приложения

Добавлено 23.02.15, 17:14

Цитата wind @ 23.02.15, 17:00

компонентов для датабиндинга в стиле дельфей в джаве очень не густо, не жалуем

Вот и хотелось бы понять как вы слой бизнес-логики натягивает на "морду" web-приложения, какими библиотеками?

Сообщение отредактировано: usrjava - 23.02.15, 17:14

БД надо выбирать, прежде всего, по планируемым нагрузкам, а в отношении Java главное, чтобы был JDBC-драйвер. Для Firebird он есть.

ORM, если не будете использовать Glassfish, то на Hibernate, если будете -- сперва попробовать EclipseLink, который по умолчанию.

Spring я не пробовал. Изучать Java EE начал с чтения вешеуказанной документации (которая написана с упором на Glassfish, что не удивительно), взял Glassfish и на нём остался. Нравится. Про Spring где-то пишут, что "он лучше, т.к. потребляет меньше ресурсов (Java EE избыточен)", где-то что "Spring при нынешнем Java EE актуален только для поддержки старых приложений, зачатых, когда Java EE не был так хорош". За всех говорить не буду, но если поискать по вакансиям -- Spring встречается на порядок чаще -- может, потому, что тех самых "старых приложений", написанных на нём, на порядок больше, чем новых стартапов. Java EE, кроме Glassfish, полностью реализован в JBoss, но его тоже не пробовал. Своё приложение на Glassfish начал делать два года назад (сейчас оно успешно используется), тогда были актуальны Glassfish 3.2 и Java EE 6, сейчас Glassfish 4.1 и Java EE 7.

JSF (Java Server Faces) -- фреймворк для Web-приложений, весьма специфический. Может использоваться, как шаблонизатор, но общие возможности шире. Заточен именно под Enterprice. Работать будет хорошо, если пользователь будет только нажимать на "его" кнопки и не будет смотреть на адресную строку. Иначе, например, после отправки данных из формы и отображения новой страницы в адресной строке останется URL старой. Это ещё ничего, но если там будет новая подобная форма, ведущая на третью страницу -- при переходе мы увидим URL предыдущей (второй), что окончательно сбивает с толку.

В качестве более простого шаблонизатора есть JSP, может, что ещё.
Так же можно обратить внимание на GWT (Google Web Toolkit).

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

Цитата usrjava @ 23.02.15, 17:12

Вот и хотелось бы понять как вы слой бизнес-логики натягивает на "морду" web-приложения, какими библиотеками?

наверное вам нужен grails

Цитата kopilov @ 23.02.15, 18:21

Google Web Toolkit

на сколько востребован и заморочен?

Цитата usrjava @ 23.02.15, 20:24

на сколько востребован и заморочен?

Я, опять же, не использовал. (Вообще, разработка Web-приложений под браузеры не входит в мои обязанности: пишу только backend с SOAP и RESTful-интерфейсами. Тот же JSF поковырял только в качестве эксперимента.)

Впервые узнал о нём на первых курсах по Java -- это был 2008 год, я учился на 3 курсе. Сделать задание по GWT предлагалось по желанию в конце курса, у меня тогда хватало других заморочек.

Насколько востребован сейчас -- наверно, лучше оценить по числу упоминаний в вакансиях. У меня на паре собеседований спросили: знаком или нет.

Не хотел бы реализовать модели отображения, методы ввода/вывода и само отображение (view) на сервере.
Хотелось бы сделать так - реализовать серверную часть (в качестве контейнера беру сервер Tomcat), не знающая ничего о UI, она только предоставляет доступ к данным и функциям их обработки (используются протоколы REST). Затем проектируем UI и вот он уже обращается к этим сервисам и функциям на сервере. То что я нашел из технологий, позволяющие реализовать построение такого UI - это AngularJS, JQuery. Очень не удобные - приходится писать по сути на JavaScript. Есть ли что-то типа такого: мы в IDE проектируем наши web-страницы (размещаем контролы: меню, кнопки, таблицы и т.п.) и делаем связку с нашим сервером. В этом плане проектирование именно GUI очень классно сделано в Delphi. Видел на C# проектирования их *.asp-страниц по этому принципу - но все равно как-то убого. Скажите, пожалуйста, не придумали каких-либо фреймворков на Java для подобного проектирования GUI. Вроде при разработке GWT что-то похожее хотели сделать, но там обе части и серверная и клиентская должны быть, по-моему, на GWT.

Цитата usrjava @ 11.03.15, 12:38

не придумали каких-либо фреймворков на Java

Цитата usrjava @ 11.03.15, 12:38

не знающая ничего о UI, она только предоставляет доступ к данным и функциям их обработки (используются протоколы REST).

Вы понимаете, что это взаимоисключающие параграфы? Либо вы ищите то, что реализовано для java, либо реализуете по отдельности на

Цитата usrjava @ 11.03.15, 12:38

AngularJS, JQuery.

и пишите на очень удобном и предназначенном для написания UI джаваскрипте.

Цитата usrjava @ 11.03.15, 12:38

Очень не удобные - приходится писать по сути на JavaScript.

Ну так браузеры java байт-код то выполнять не умеют.
Умеют JavaScript.

В GWT - там код клиентской части, написанной на Java, компилируется в JavaScript - и браузер выполняет уже этот скомпилированный js.

Ну еще есть апплеты (это для которых плагин в браузеры надо ставить), но копать в эту сторону в 2014 году попахивает легкой некрофилией

Сообщение отредактировано: @@@ - 11.03.15, 13:53

Цитата Астарот @ 11.03.15, 13:15

на очень удобном и предназначенном для написания UI джаваскрипте.

проблема в том, что раньше программист по сути в одном лице мог сделать полное ПО от начала до конца (ему досточно было знать сам язык (C++, Object Pascal), IDE (VS C++, Delphi), SQL + Субд(какую-либо)) сейчас же приходится использовать целый зоопарк технологий. Как было бы здорово если мы берем и дизайн web-приложения клепаем как в Delphi. В Google сидят не дураки, поэтому и предпринимались попытки сделать подобное - фреймворк GWT. Т.е. Java-программист продолжает писать на java и не заморачивается с html, javascript, php, ccs

Цитата usrjava @ 11.03.15, 14:05

Как было бы здорово если мы берем и дизайн web-приложения клепаем как в Delphi

Дельфи мертв. Задумайтесь над этим фактом.

Цитата usrjava @ 11.03.15, 14:05

В Google сидят не дураки, поэтому и предпринимались попытки сделать подобное - фреймворк GWT. Т.е. Java-программист продолжает писать на java и не заморачивается

Так а чем он вам в итоге не угодил то?

Цитата Астарот @ 11.03.15, 17:31

Дельфи мертв. Задумайтесь над этим фактом.

Да, кстати. Пара полезных статей на эту тему:
Визуальное программирование
Зоопарк технологий -- зоопарк специалистов

И стоит облазить этот сайт в поисках других полезных советов, я сам с него начинал. Это было в 2008 году (примерно тогда многие статьи и написаны), но большинство статей если и устарели, то не сильно.