CODEWITHSUNDEEP
javamodel-view-controllerjavafxmodeljavafx-8
Matthew McPeak
Matthew McPeak

Reputation: 17924

JavaFX 8: Separation of model/domain from view

I am just learning JavaFX 8. It seems if you want to display something in a control, say a TableColumn, you need that something to be an instance of ObservableValue, for example, a SimpleStringProperty.

So, in the commonly used Person object, I might have a SimpleStringProperty for "firstName", and then I would be able to use that as the value of TableColumn, like this:

TableColumn<Person, String> firstNameCol = 
            new TableColumn<Person, String>("First Name");
firstNameCol.setCellValueFactory(
            new PropertyValueFactory<Person, String>("firstName"));

But, Person is what I would call a "domain" class -- something that my model would freely refer to and use. I don't want my domain and model layers to be aware of / dependent on the fact that the application is displayed using JavaFX.

Am I right in thinking that the model/domain should be kept pure in that regard? If so, what is the best way to accomplish that using JavaFX? E.g., should I write adapter classes somehow for my domain objects to present them with ObservableValues?

Upvotes: 2

Views: 1282

Answers (3)

S&#233;bastien B.
S&#233;bastien B.

Reputation: 545

The next version (8.6.0 in active dev) of JRebirth will allow to generate these FXJO (javaFX Java Object) from POJO (Plain Old Java Object) by using annotation processor.

Or by directly parsing an ecore file.

It can give you the opportunity to not alter your Business Model with UI related stuff like Properties.

Upvotes: 0

user3453226
user3453226

Reputation:

Why do you want to avoid using any JavaFX class at all?

JavaFX Properties (found in the javafx.beans.property package) are just an extension to the regular JavaBeans properties.
They are part of the JavaFX Properties and Bindings framework, which doesn't depend on the JavaFX Toolkit to have its functionality implemented, nor does it require your application to leverage the JavaFX UI classes in order to build its graphical user interface. It can therefore be used as a standalone facility anywhere in your code, without having to worry about the model/domain being coupled to this particular implementation of the view.

You should consider the JavaFX Properties and Bindings framework a general utility that is inherently indipendent of the implementation of the view due to its nature, just like is any other general-purpose library (e.g. Guava). You could, for example, switch to a Swing application at any time, while still keep using it.

But if you still prefer to not leverage its functionality when possible, then there's a case when you can actually do so: if what's being presented isn't going to change (e.g. the state corresponding to the table model in your domain class is immutable), and standard property getters are present, then, as per the PropertyValueFactory documentation:

There is fall-through support for attempting to call get<property>() or is<property>(). If a method matching this pattern exists, the value returned from this method is wrapped in a ReadOnlyObjectWrapper and returned to the TableCell. However, in this situation, this means that the TableCell will not be able to observe the ObservableValue for changes.

Avoid adapters; they are meant to be used with legacy code only that cannot be altered in any way.

Related Posts

Upvotes: 2

john16384
john16384

Reputation: 8044

It is certainly wise to keep your domain model pure, and not tie it to any specific framework as you may need to use those objects in other contexts (database storage, exposing them in a REST API, doing batch processing, etc.).

Changing your domain model to use JavaFX properties would add a lot of extra baggage to those classes that you need to avoid in other scenario's.

JavaFX however does have a standard way of dealing with this situation so you can connect your domain model to its controls easily, and it works in a way you already suggested, using adapters from its javafx.beans.property.adapter package.

Using these adapters however won't make your controls respond to values changing in your domain objects like they would with SimpleStringProperty for example.

It will depend on your requirements if that is a problem, if it is however you may consider modifying your domain model objects to add PropertyChangeListener support. This is a relatively light weight change (vs. full JavaFX Properties) and would not make you depend on JavaFX (only on java.beans which is less problematic).

See this answer for a thorough explanation of how to use domain model classes in JavaFX directly: JavaBean wrapping with JavaFX Properties

Upvotes: 5

Related Questions