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

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?

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.

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).