JavaFX - правильный способ использования свойств с объектами домена

10

JavaFX предоставляет множество новых объектов Property, например, javafx.beans.property.DoublePropertyкоторые позволяют вам определять поля, которые можно автоматически наблюдать и синхронизировать.

Во многих примерах JFX класс модели MVC имеет ряд этих полей свойств, которые затем могут автоматически привязываться к представлению.

Тем не менее, это, кажется, побуждает нас помещать свойства JFX в наши объекты Domain (если вы предполагаете, что класс Model будет объектом домена), что кажется мне плохим разделением проблем (то есть помещение кода GUI в Domain ).

Кто-нибудь видел, чтобы эта проблема решалась в «реальной жизни», и если да, то как это было сделано?

properties javafx domain-objects

— pjm56
источник

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

— Джек Стоун

Sun и Oracle уже несколько лет непрерывно работают над JavaFX. Недавний значительный сдвиг состоял в том, чтобы прекратить использование языка программирования «JavaFX Script», который требовался для использования JavaFX, и перейти на использование обычной Java. Этот сдвиг был вызван плохим внедрением и затратами на поддержку совершенно нового языка программирования.

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

4

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

То, что я сделал, я разделил каждый класс в модели на два: реальный класс модели, который имеет возможность загружать свое содержимое из базы данных, знает, как он изменяет свое состояние и т. Д. И т. Д. ... и класс представления, который определяет внешний вид. на экране. Последний будет содержать все классы Property.

Такой же дизайн вы найдете в любой среде MVC, например, в Swing. Просто здесь нет выхода из этого.

— Ханнес Р.
источник

Фреймворк, который заставляет вас применять хорошие принципы дизайна или взрывается, если вы этого не сделаете. Как парень .NET, это очень знакомо мне.

— MattDavey

0

Спустя почти 7 лет этот вопрос остается в силе, как и раньше.

По моему мнению, javafx никогда не должен импортироваться ни одним из классов, принадлежащих модели. Однако они могут работать очень хорошо, если вы используете MVVM в сочетании с архитектурой MVC. В этом смысле

сущности = (доменная) модель ( M )
FXML файлы = вид ( V )
контроллер по-прежнему контроллер ( С )
модель представления ( VM ) = новый набор классов данных, которые содержат только свойства javafx и ссылку на фактический объект домена (M), который он представляет. Далее он может передавать вызовы методов бизнес-логики этому объекту, выступая в качестве составного / декоратора.

Другой способ увидеть вещи - представить класс контроллера как часть представления, поскольку все, что он делает, - это связывает модель представления с представлением (данные и действия). Так что это можно легко назвать предъявителем или даже связывателем. Однако это зависит от того, как вы используете контроллер. Если вы добавите логику для манипулирования моделью представления в классе Controller, то она заслуживает своего имени, и у вас есть архитектура, представленная выше. Если класс контроллера привязывает только данные модели к элементам пользовательского интерфейса и ActionEvents к методам модели, то вы, как правило, имеете мутантную архитектуру MVVM, представленную ниже.

Я думаю, что эти архитектуры как-то соответствуют идеям дяди Боба о чистой архитектуре (уровень представления).

— Влад Кэлин Бузеа
источник