Я довольно новичок (или, может быть, старичок) в разработке графического интерфейса. Теперь, когда вы копаетесь, кажется, что можно использовать огромное количество различных фреймворков. В настоящее время я создал java-приложение, которое очищает все виды метаданных файлов и приложений в базу данных PostgreSQL. Теперь эта часть почти готова, и данные (около 20000 строк) хранятся в базе данных сервера в ожидании дальнейшего использования. Я предполагаю, что в конечном итоге в базе данных могут быть сотни тысяч строк в нескольких таблицах, может быть, миллион или два максимума.
Один путь был бы продолжен с Java Swing/FX, но интерфейс должен быть действительно независимым от ОС и легко подходить, что указывает на веб-решения. Похоже, что апплеты — это довольно старая вещь, и к настоящему времени у JSF есть много жизнеспособных конкурентов. Требования к графическому интерфейсу:
Первой мыслью было построить это исключительно на сервере; построение всех древовидных карт и т. д. на основе запросов пользователей. Однако при наличии нескольких пользователей это, вероятно, создаст значительную нагрузку на сервер. Поэтому подумал, что если будет минимальное количество логики кода на стороне сервера, просто для защиты/изоляции запросов к базе данных, формирования основного материала HTML/CSS, а затем встроенной логики Javascript для рисования графики, интерпретации пользовательского ввода и т. д. на стороне клиента ? В настоящее время одна загадка заключается в том, как эти два мира будут общаться друг с другом, я имею в виду, как часть javascript запрашивает информацию со стороны сервера? Требуются ли для этого веб-сокеты или может ли некоторая логика приложения на стороне сервера действовать как интерфейс REST/API для кода javascript? Может быть, просто иметь промежуточное программное обеспечение REST Джерси/качели Java "что-то" между базой данных и веб-страницей, предоставляющей данные JSON для логики Javascript. Сейчас играю с Hibernate, но не уверен, подойдет ли он к этому сценарию...
Писал код на Java, C, Python, JS и некоторых других древних языках + немного Node.js, PHP и Perl. Предпочитаю Java и JS, но если есть веская причина использовать что-то другое, это не должно быть проблемой. В настоящее время используется Netbeans (иногда Eclipse) и исследованы некоторые примеры проектов Web, JavaFX, HTML5, JSF, Maven, которые у него есть. Также пытались исследовать Spring, Hibernate, Vaadin, Wicket, JSF и еще много чего. Все говорят, насколько они просты и превосходны, но чем больше я читаю/тестирую их, тем больше кажется, что они не всегда так уж полезны, создавая всевозможный дополнительный код здесь и там. Итак, после нескольких дней расследований, я все еще очень запутался во всех этих возможностях, и прежде чем навсегда потеряться в этих джунглях, Я подумал, что, может быть, какой-нибудь гуру подскажет, по какому пути должен пойти этот n00b? Просто пытаюсь избежать ситуации, когда половина дела сделана, а затем нужно изменить фреймворк, потому что отсутствие какой-то функции или обслуживание становится непосильным.
Маршрут Java-апплета почти мертв. Все производители веб-браузеров прекращают поддержку Java-апплета и подобных сред выполнения плагинов, таких как Flash и Silverlight , из-за ужасных проблем с безопасностью.
Точно так же в Java технология Applet теперь устарела и, вероятно, в конечном итоге будет прекращена.
Если вы уже делаете успехи в создании приложения Swing/JavaFX, нет причин не выпускать его. Такое приложение, безусловно, кроссплатформенное. Благодаря модуляризации Java, выполненной в Java 9/10/11, вы можете использовать такие инструменты, как jlink, для создания настраиваемой сборки JVM, которая будет связана с вашим приложением в виде единого исполняемого файла.
Если вы решили, что веб-приложение — это то, что вам нужно, и у вас уже есть навыки работы с Java, то Vaadin — очевидный выбор. Vaadin работает на Java, а состояние вашего приложения находится на стороне сервера в JVM. Вы пишете и свою бизнес-логику, и код пользовательского интерфейса на чистой Java. Фреймворк Vaadin устанавливает на клиенте библиотеку JavaScript, с помощью которой динамически создаваемый пользовательский интерфейс веб-стандартов отображается удаленно на стороне клиента.
Связь между клиентом и сервером осуществляется автоматически с использованием технологии Java Servlet, HTTP, HTTP/2 и WebSocket, в зависимости от возможностей вашего веб-браузера, веб-сервера и возможностей сети.
Что касается разделов вашего макета пользовательского интерфейса, которые координируют и реагируют на взаимодействие с пользователем, это и есть цель Vaadin. Пользователь нажимает кнопку или вводит текст в поле, Vaadin передает это пользовательское событие серверному Java-приложению, где ваш код реагирует и обновляет состояние других виджетов. Vaadin автоматически сообщает о новом состоянии этих других виджетов обратно в веб-браузер, где обновляется их визуальное отображение.
Что касается виджета дерева, Vaadin 8 уже предоставляет два виджета: a Treeи a GridTree.
Что касается вашего графического визуализатора на основе Java, это проблема. С Vaadin на стороне клиента нет Java. На стороне клиента используются только стандартные веб-технологии, такие как JavaScript, CSS, DOM, AJAX и т. д. Если ваша библиотека GraphStream может работать в автономном режиме, то вы сможете выполнять рендеринг на стороне сервера с готовым изображением, отправленным в веб-браузер. для отображения.
Если вам нужна интерактивность, вам нужно будет найти инструмент JavaScript, эквивалентный GraphStream. Такой инструмент можно обернуть как виджет Vaadin для доступа к нему на стороне сервера в Java. В Vaadin 8 такая упаковка выполняется через GWT, Google Web Toolkit. В Vaadin 10 и более поздних версиях, известных как Vaadin Flow , такая упаковка становится намного проще за счет внедрения технологии веб-компонентов вместо GWT.
Вы упомянули Hibernate , но это не имеет отношения к вашему вопросу. Этот проект предназначен в первую очередь для автоматизации некоторых взаимодействий с базой данных. Не имеет ничего общего с пользовательским интерфейсом или большим приложением. Некоторые вспомогательные подпроекты, такие как реализация Bean Validation, служат промежуточной цели между пользовательским интерфейсом и базой данных.
Просто пытаюсь избежать ситуации, когда половина дела сделана, а затем нужно изменить фреймворк, потому что отсутствие какой-то функции или обслуживание становится непосильным.
При любом выборе технологии вы должны сосредоточиться на одноразовой проверке концепции, прежде чем приступать к реальной реализации. Создайте поддельное приложение, которое частично затрагивает все области, запланированные в вашем приложении. Опробуйте каждую часть технологии, чтобы убедиться, что она соответствует вашим потребностям. После того, как это будет доказано, выбросьте это поддельное приложение и начните заново с уверенностью, что вы сможете выполнить свою миссию.
Спасибо @Basil за исчерпывающий ответ. Делал так же, как вы сказали, пробуя разные подходы с небольшим объемом тестовых данных. Первым путешествием был PHP, от которого я вскоре отказался, потому что PHP кажется несколько неуклюжим, безопасность немного сомнительна, а дальнейшее обслуживание с растущим комплексом сайтов может стать утомительным. Теперь поиграл с Ваадином некоторое время, и это кажется довольно хорошим вариантом. Поддержка сообщества могла бы быть лучше, но все же немного потеряна из-за своей иерархии, внутренней функциональности и всех новых причудливых нотаций Java 1.8 (!) :s
Тем не менее, я все еще балансирую между веб-интерфейсом и настольным приложением. Создание веб-приложения типа ide кажется намного более сложным, чем аналогичное классическое настольное приложение. Таким образом, Swing/JavaFX по-прежнему рассматривается как запасной вариант, если создание веб-интерфейса становится слишком сложным.
Базиль Бурк
БренБарн