@ShinRa11 фев 2018 в 18:41

И на улицу JavaFX тоже придет Spring

20 мин

26K

Java * Графические оболочки *

Туториал

Из песочницы

Recovery Mode

+22

Комментарии 23

@Moxa 11 фев 2018 в 21:23

за что нам такое счастье? неужели нет другого способа в базу ходить?

@ShinRa 12 фев 2018 в 03:38

Что вы имеете ввиду? Использование Spring, datasourse и конфига?

@PloadyFree 12 фев 2018 в 03:28

Может, я невнимательно смотрел, но где здесь Spring Boot?

@ShinRa 12 фев 2018 в 03:29

Спасибо, мой косяк, как говорится, ляпнул не подумав. Исправил дабы не вводить людей в заблуждение

@fogone 12 фев 2018 в 03:39

Суровая интеграция, бессмысленная и беспощадная.

@tamsus 12 фев 2018 в 03:59

Ну для начала у Вас не Spring Boot, а обычный Spring с xml конфигурациями. Boot позволяет как раз таки избегать application-context.xml и так далее. Потом, SQL запросы в коде? Почему бы не использовать JPA и Hibernate для таких вещей?

@ShinRa 12 фев 2018 в 04:00

К сожалению к Hibernate и JPA не удалось пока прикоснутся.

@AstarothAst 12 фев 2018 в 08:41

Да бросьте, если запрос не меняется, да к тому же достаточно элементарен, то почему бы не положить его в код ровно там, где он применяется, и где его будет ожидать увидеть тот, кто код читает? jpa, hibernate, гвоздь, микроскоп…

@tamsus 12 фев 2018 в 11:38

Почему же с таким успехом не написать обычный метод, к примеру findOneByName, без SQL да в интерфейсе, наследуемом от JpaRepository и поместить его на сервисный слой? Что мешает понять этот код и найти его там, где ожидается?

@AstarothAst 13 фев 2018 в 06:56

Ну, нашли вы этот код, а он читает данные из БД, а у вас проблема как раз в том, что возвращается что-то не то. В итоге все равно вы обречены спуститься на уровень базы, данных и селектов. JPA это абстракция, и как любая абстракция имеет положительные и отрицательные эффекты. В случае таких вот элементарных запросов, имхо, отрицательных эффектов гораздо больше, чем положительных. Запрос + rowmapper — почему бы нет?

@Lure_of_Chaos 12 фев 2018 в 05:42

Слишком много кода для слишком малых возможностей и гибкости.
Я делал подобное, в зависимости от потребностей пришлось написать 2-5 классов, которые потом не нужно трогать.

Писать абстрактный класс контроллера с необходимостью его расширять только чтобы был доступен спринговый контекст?
До сих пор спринг конфигурируется через xml?
… вот счастье-то.

@ShinRa 12 фев 2018 в 05:55

Вы хотите сказать, что конфигурация через xml умерла?

@AstarothAst 12 фев 2018 в 06:16

И давно.

@gotozero 12 фев 2018 в 06:05

Есть уже проекты которые делают такое из коробки.
github.com/roskenet/springboot-javafx-support

@PqDn 12 фев 2018 в 06:44

Щас рекомендуется для спринг приложении использовать спринг бут. Во первых легче, во вторых некоторая гарантия, что не будет конфликтов версий, В третих не надо плагины самому прописывать на компилятор и на сингл джар
Вот дока на последнею версию docs.spring.io/spring-boot/docs/2.0.0.RC1/reference/htmlsingle

@APXEOLOG 12 фев 2018 в 07:55

Spring Boot это этакая сборная солянка для веб-сервера. Автору веб-сервер не нужен, ему видимо нужен DI и различные плюшки спринга. В таком случае лучше просто добавить те модули, которые нужны

@PqDn 12 фев 2018 в 09:27

Ну спринг бут можно так и настроить

@aol-nnov 12 фев 2018 в 08:21

Spring Boot это этакая сборная солянка для веб-сервера.

Нет.

"In Spring Boot, to create a non-web application, implement CommandLineRunner and override the run method"

@Mogaba 12 фев 2018 в 13:08

<fx:include> позволяет делать инъекцию дочернего контроллера:

main.fxml

<fx:include source="productTable.fxml" fx:id="table" />

MainController.java

@FXML
private ProductTableController tableController;

@ShinRa 12 фев 2018 в 13:09

Не совсем понял, либо тут ошибочка и fx:id должен быть равен tableController?

@Mogaba 12 фев 2018 в 14:22

Имя поля для контроллера должно быть составлено из значения атрибута fx:id элемента <fx:include> (в данном случае «table») с добавлением слова «Controller». Когда лоадер видит такое поле (с аннотацией @FXML, естественно), он инжектит в него контроллер, который указан в include-файле.

@fspare 12 фев 2018 в 13:20

Поправьте меня если я не прав, но насколько это хорошее решение делать толстого клиента?

Может быть было бы резоннее сделать слой который ходит в базу данных не частью JavaFX приложения, а частью веб сервиса который предоставлял бы эту функциональность? А для JavaFX приложения использовать нечто более легковесное, чем Spring? Например, Google Guice или что-то другое для Dependency Injection?

Просто я пытался использовать Spring для десктопных приложений и пришел к выводу, что он довольно-таки тяжелый(именно стадия инициализации занимает много времени да и куча библиотек за ним тянется из-за чего конечный разме jar файла получается довольно-таки большим, да и памяти отъедается прилично на ПК пользователя) и для десктопа именно я его бы не использовал, хотя на стороне сервера это решение себя хорошо зарекомендовало.

Все вышесказанное — мое ИМХО — было бы интересно услышать мнение других сторон.

@MisterParser 13 фев 2018 в 12:56

Спасибо за статью! Как раз позавчера писал своё первое JavaFX приложение и использовал Spring для удобной работы с настройками пользователя. Почерпнул идеи из вашего примера и может быть даже напишу статью о своей разработке.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий