JavaFX - правильний спосіб використання властивостей з об’єктами домену

10

JavaFX надав купу нових об'єктів властивості, таких як, javafx.beans.property.DoublePropertyякі дозволяють визначати поля, які можна автоматично спостерігати та синхронізувати.

У багатьох прикладах JFX клас класу MVC має ряд цих полів властивостей, які потім можуть автоматично прив'язуватися до подання.

Однак це, здається, спонукає нас розмістити властивості JFX у наших об’єктах Домену (якщо ви вважаєте, що клас Model буде доменним об’єктом), що сприймає мене як слабке розділення проблем (тобто, розміщення коду GUI у домені ).

Хтось бачив, як ця проблема вирішується в «реальному житті», і якщо так, як це робилося?

properties javafx domain-objects

— pjm56
джерело

Виправте мене, якщо я помиляюся, але я зрозумів, що JavaFX був у тому, що він був відкладений компанією Sun у 2008 році до придбання Oracle, і він був реконструйований на ринок лише знеціненням Silverlight та зниженням Flash на пристроях Apple. Можливо, ви маєте рацію, що вона щільно поєднана з видом, і первісна причина була затримана на сонці. Просто думка.

— Джек Стоун

Sun і зараз Oracle кілька років постійно працюють над JavaFX. Останнім головним зрушенням було припинення мови програмування «JavaFX Script», яка була необхідна для використання JavaFX, та переходу до використання звичайної Java. Цей зсув був зумовлений поганим прийняттям та витратами на підтримку абсолютно нової мови програмування.

— Стюарт Маркс

4

Я бавився з JavaFX 2.0, і я вважаю, що це ваше питання. Не справжній виробничий код, а лише особистий проект, але я зіткнувся з тією ж проблемою, яку ви згадуєте вище. Вся модель, як правило, стає залежною від рамки 2D, і мені це не подобається.

Що я зробив, я розділив кожен клас у моделі надвоє, реальний модельний клас, який має можливість завантажувати його вміст із бази даних, знає, як він змінює свій стан і т.д. тощо ... і клас представлення, який визначає зовнішній вигляд на екрані. Останній містив би всі класи властивостей.

Ви знайдете таку ж конструкцію в будь-якій структурі MVC, як Swing. це просто те, що тут не врятується зробити це.

— Ханнес Р.
джерело

Рамка, яка змушує вас застосовувати добрі принципи дизайну або підірвати обличчя, якщо цього не зробити. Як хлопець .NET, це мені дуже добре знайоме.

— MattDavey

0

Майже через 7 років, і це питання все ще є таким же актуальним, як і раніше.

На мою думку, javafx ніколи не повинен бути імпортований жодним з класів, що належать до моделі. Однак вони можуть працювати дуже добре, якщо ви прийняли MVVM у поєднанні з MVC архітектурою. У цьому сенсі

сутні = модель (домен) ( M )
Файли FXML = перегляд ( V )
контролер все ще є контролером ( C )
view-model ( VM ) = новий набір класів даних, що містять лише властивості javafx та посилання на фактичний об'єкт домену (M), який він представляє. Він може передавати цей виклик методом ділової логіки далі, виступаючи композитором / декоратором.

Інший спосіб бачити речі - це уявити клас контролера як частину перегляду, оскільки все, що він робить, - це зв’язати модель перегляду з поданням (дані та дії). Тож це можна було б легко назвати ведучим або навіть біндером. Однак це залежить від способу використання контролера. Якщо ви додасте логіку для маніпулювання моделлю view у класі Controller, то вона заслуговує на свою назву, і у вас є архітектура, представлена вище. Якщо клас контролера прив'язує дані моделі лише до елементів інтерфейсу, а ActionEvents - до модельних методів, тоді, як правило, архітектура мутантів MVVM представлена нижче.

Я думаю, що ці архітектури якось відповідають ідеям дядька Боба щодо чистої архітектури (презентаційний шар).

— Влад Калін Бузеа
джерело