JavaFX - właściwy sposób używania właściwości z obiektami domeny

10

JavaFX dostarczył kilka nowych obiektów Property, takich jak javafx.beans.property.DoublePropertyktóre pozwalają zdefiniować pola, które mogą być automatycznie obserwowane i synchronizowane.

W wielu przykładach JFX klasa modelu MVC zawiera wiele tych pól właściwości, które mogą następnie automatycznie łączyć się z widokiem.

Wydaje się to jednak zachęcać do umieszczania właściwości JFX w naszych obiektach Domain (jeśli założymy, że klasa Model będzie obiektem Domain), co uderza mnie jako słabą separację problemów (tj. Umieszczenie kodu GUI w domenie ).

Czy ktoś widział rozwiązanie tego problemu w „prawdziwym życiu”, a jeśli tak, to w jaki sposób?

properties javafx domain-objects

— pjm56
źródło

Popraw mnie, jeśli się mylę, ale moje zrozumienie JavaFX było takie, że firma Sun odłożyła ją na półkę w 2008 r. Przed zakupem Oracle i została odnowiona na rynku z wycofaniem Silverlight i odrzuceniem Flasha na urządzeniach Apple. Może masz rację, że jest ściśle powiązany z widokiem i pierwotnym powodem, dla którego został wstrzymany na słońcu. Tylko myśl.

— Jack Stone,

Sun, a teraz Oracle, nieprzerwanie pracują nad JavaFX od kilku lat. Ostatnia ważna zmiana polegała na zaprzestaniu używania języka programowania „JavaFX Script”, który był wymagany do korzystania z JavaFX, i na przejściu na zwykłą Javę. Zmiana ta była spowodowana słabą adaptacją i kosztem obsługi całkowicie nowego języka programowania.

— Stuart Marks

4

Bawiłem się JavaFX 2.0, o którym, jak sądzę, chodzi o twoje pytanie. Nie prawdziwy kod produkcyjny, tylko osobisty projekt, ale napotkałem ten sam problem, o którym wspomniałeś powyżej. Cały model staje się zależny od frameworka 2D i nie podoba mi się to.

To, co zrobiłem, podzieliłem każdą klasę w modelu na dwie części, prawdziwą klasę modelu, która ma możliwości ładowania zawartości z bazy danych, wie, jak zmienia swój stan itp. Itd. Oraz klasę reprezentacji, która decyduje o wyglądzie na ekranie. Ten ostatni zawierałby wszystkie klasy Property.

Ten sam projekt znajdziesz w dowolnym frameworku MVC, takim jak Swing. po prostu tutaj nie ma ucieczki przed zrobieniem tego.

— Hannes R.
źródło

Ramy, które zmuszają cię do stosowania dobrych zasad projektowania lub wysadzają cię w twarz, jeśli nie. Jako facet .NET jest mi to bardzo znane.

— MattDavey,

0

Prawie 7 lat później i to pytanie jest nadal aktualne.

Moim zdaniem javafx nigdy nie powinien być importowany przez żadną klasę należącą do Modelu. Mogą jednak działać bardzo dobrze, jeśli zastosujesz MVVM w połączeniu z architekturą MVC. W tym sensie

podmioty = (domena) model ( M )
Pliki FXML = widok ( V )
kontroler nadal jest kontrolerem ( C )
the view-model ( VM ) = nowy zestaw klas danych, który zawiera tylko właściwości javafx i odniesienie do rzeczywistego obiektu domeny (M), który reprezentuje. Może przekazywać wywołania metod logiki biznesowej dalej do tego obiektu, działając jako kompozyt / dekorator.

Innym sposobem postrzegania rzeczy jest myślenie, że klasa kontrolera jest częścią widoku, ponieważ wystarczy powiązać model widoku z widokiem (danymi i akcjami). Można go więc łatwo nazwać Prezenterem, a nawet segregatorem. Zależy to jednak od sposobu korzystania z kontrolera. Jeśli dodasz logikę do manipulowania modelem widoku w klasie Controller, wówczas zasługuje na swoją nazwę i masz architekturę przedstawioną powyżej. Jeśli klasa kontrolera wiąże dane modelu tylko z elementami interfejsu użytkownika, a ActionEvent z metodami modelowymi, wówczas architektura mutantów MVVM ma tendencję do przedstawiania poniżej.

Myślę, że te architektury w jakiś sposób odpowiadają pomysłom wujka Boba dotyczącym czystej architektury (warstwa prezentacji).

— Vlad Călin Buzea
źródło