JavaFX FXML, для чего Controller?

В уроках об FXML говорится об пользе и преимуществах разделения интерфейса и логики в программах, но есть ещё непонятный мне класс "Controller" (помимо классов логики и интерфейса) . В чём его идея, какую функцию он выполняет? В чём преимущество такого подхода?

Ответ

Возможно, Вам будет интересно мое мнение:
Лично я считаю, что термин "controller" в документации FXML следует воспринимать не более, чем то, что в других технологиях называется "code behind".
То есть это просто дополнительный код для выполнения задач связанных с отображением "вида" (view). (Под "видом" я здесь имею в виду конкретный участок пользовательского интерфейса).
FXMLLoader с помощью инъекций связывает объект контроллера с деревом объектов, которое он нагенерил по fxml-разметке. А также предоставляет некоторые другие возможности, например, одностороннюю привязку ("${expression}") атрибутов-свойств и прочее.
Но вот, к примеру, двусторонняя привязка ("#{...}") FXMLLoader'ом так до сих пор не реализована, и класс контроллера — это как раз подходящее место для ее описания.
Без сомнения, то, что будет в этом "code behind" полностью зависит от вашего подхода и самодисциплины. Как со стороны размещения бизнес-логики, так и со стороны разделения зон ответственности программиста и дизайнера.
Именно Вам решать, будет ли этот класс толстым носителем логики, или лишь тонкой прослойкой между моделью и видом.
При этом, даже, если вы будуте использовать какой-то определенный фреймворк (например, mvvmFx), то это не спасет вас от возможности ошибочно разместить часть бизнес-логики модели в "code behind" определенного вида (эта ошибка может и обнаружится, когда такая функциональность потребуется в другом месте).
С другой стороны, помня о том, что css-стили (кроме USER_AGENT) имеют определенное преимущество над JavaFx-свойствами узлов, в контроллере имеет смысл описывать настройки интерфейса с помощью JavaFx-свойств, а не заданием css-стилей — для того, чтобы дизайнер впоследствии смог исправить интерфейс указанием css-стилей. И даже в этом случае программист может сказать свое "последнее слово", восстанавливая значение свойства в обработчике изменения этого свойства ;)

Под словами "определенное преимущество" я имею ввиду то, что css-стиль перекрывает соответствующее ему свойство. Но только в момент перепроверки стилей. А до этой перепроверки будет действовать свойство. Например, можно установить какое-либо свойство узлу (в обработчике нажатия другой кнопки) и это будет отражено на экране, но при наведении на узел курсора мыши, узлу устанавливается псевдокласс hover и выполняется переустановка его стилей в соответствии с псевдоклассом, тем самым свойство будет заменено стилем. После того, как курсор мыши будет убран с узла, у него будет также убран псевдокласс hover. Это изменение псевдоклассов опять повлечет переустановку стилей узла, но в этих стилях не указано то изменение, которое делалось для свойства в обработчике. Поэтому свойство на экране отражено не будет, хотя оно и работало вначале некоторое время.