JavaFX has provided a bunch of new Property objects, such as javafx.beans.property.DoubleProperty which allow you to define fields which can be automatically observed and synchronised.

In many JFX examples, the MVC model class has a number of these Property fields, which can then bind automatically to the view.

However, this seems to be encouraging us to put JFX properties into our Domain objects (if you assume that the Model class is going to be a domain object), which strikes me as a poor separation of concerns (i.e. putting GUI code in the Domain).

Has anyone seen this problem being solved in 'real life' and, if so, how was it done?

  • Please correct me if I am wrong, but my understanding of JavaFX was that it was shelved by Sun in 2008 prior to Oracle purchase, and has only been refurbished to the market with the deprecation of Silverlight and Decline of Flash on apple devices. Maybe you are correct that it is tightly coupled to the view, and an original reason it was put on hold at sun. Just a thought. – Jack Stone Jul 7 '12 at 5:59
  • Sun and now Oracle have been working continuously on JavaFX for several years. The recent major shift was to discontinue the "JavaFX Script" programming language that was required to use JavaFX, and to switch to using ordinary Java. This shift was driven by poor adoption and expense of supporting an entirely new programming language. – Stuart Marks Jul 17 '12 at 6:46

I have been playing around with JavaFX 2.0, which I assume your question is about. Not real production code, just a personal project, but I ran into the same problem that you mention above. The entire model tends to become dependent from the 2D framework, and I don't like it.

What I did that I split every single class in the model in two, the real model class, which has the capabilities to load its contents from database, knows how it alters its state etc etc... and the representation class that decides the appearance on screen. The latter would contain all the Property classes.

You'll find the same design in any MVC framework, like Swing. it's just that here there's no escape from doing it.

|improve this answer|||||
  • A framework that forces you to apply good design principles or blows up in your face if you don't. As a .NET guy, this is very familiar to me. – MattDavey Jul 23 '12 at 12:23

Almost 7 years later and this question is still as valid as before.

In my opinion, javafx should never be imported by any of the classes belonging to the Model. However, they may work very fine if you adopt an MVVM combined with MVC architecture. In this sense the

  • entities = (domain) model (M)
  • FXML files = view (V)
  • the controller is still the controller (C)
  • the view-model (VM) = a new set of data classes that only contain javafx properties and a reference to the actual domain object (M) that it represents. It may pass business logic method calls further on to this object, acting as a composite/decorator.


Another way to see things is to think of the controller class as being part of the view, since all it does is to bind the view-model with the view (data and actions). So it could be easily called a Presenter or even a Binder. This depends however on how you use the controller. If you add logic for manipulating the view-model in the Controller class, then it deserves its name and you have the architecture presented above. If the controller class only binds model data to UI elements and ActionEvents to model methods, then you tend to have the MVVM mutant architecture presented below.


I think these architectures somehow matche Uncle Bob's ideas on clean architecture (the presentation layer).

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.