The Situation
I'm developing a JavaFX desktop application that can be described in three parts:
- The Data
- The GUI
- The Process
The GUI is a means of seeing and editing the data and the process is a, well, a process that requires the data to perform its job. Think of the GUI as more of a supplementary piece that allows a user to customize the process.
Given the nature, the data needs to be writable to storage, and readable by the GUI. Naturally, I'm attempting to
The Problem
Let's say I have a class "Person" with members for Name and Age. In order to databind this object to a view, it must contain Property objects representing the data. This will make the class inherently non-serializable (meaning I will need to serialize it with extra code). This also kind of bloats the class, which feels like a violation of Separation of Concerns.
To solve this problem, I found a fairly standard guide on StackOverflow. Applying MVC With JavaFx
The top answer on that page suggesting using DataModels, which are basically observable versions of your models. In addition, they can have "save" and "load" methods for serialization.
This seems like a better solution, for pure data-driven applications. My situation is different, however, because even though my application is data-driven, it is also very much functional (performs actions in the background).
If I use traditional DataModels, I will need to ensure the DataModels can either be converted into non-observable models, or make sure they have methods to return all the data pieces in non-observable objects (like primitives). The functional module of the code should not need to recognize and deal with observable properties.
As a comparison, I really like how C# has properties that are inherently observable, and fit very well into WPF. C#'s approach allows me to use the data in both ways without the need for conversions to and from observable (there are exceptions, of course!).
The Question
How do I decide between these options?
- Making my models Observable by the Views AND Serializable while still functioning as basic models with primitive getters and setters.
- Creating an intermediate step of DataModels, which are Observable Objects that represent the models and bind to the views. These objects would have to be able to accept the models as a dependency, and later be converted back into the models (after being modified by the GUI).
The first option is less code. All it requires is a transient Property member for every primitive member, as well as 2 methods for serializing and deserializing. However, it feels like a direct violation of Separation of Concerns.
The second option is more code, but it completely separates the raw data and GUI through a middleman (DataModels). It requires an entirely new class for every object that I need to display in a View, with methods for conversion to and from said object! However, it feels..... "Proper".
I am limiting the scope of the question between these options, to fit better with StackExchange. However, I am open to any and all new perspectives!
Here's Some Example Code
Here is an example with datamodels
class Person implements Serializable
{
private String name;
public String getName(){...}
public void setName(){...}
}
class ObservablePerson //DataModel
{
private StringProperty name;
public ObservablePerson(Person person)
{
name = new SimpleStringProperty(person.getName());
}
public StringProperty nameProperty()
{
return name;
}
public Person toPerson()
{
...
}
}
Here is an example without datamodels:
class Person implements Serializable
{
private transient StringProperty name;
public String getName(){ return name.getValue();}
public void setName(String name){ this.name = new SimpleStringProperty(name); }
public StringProperty nameProperty()
{
return name;
}
//
public void serialize()
{
//pseudocode
write(name.getValue());
}
public void deserialize()
{
//pseudocode
name = new SimpleStringProperty(readString());
}
}
Side Notes
- The main purpose of the application is functional in nature. It performs actions in the background. It's an automation tool. Therefore, the data (and GUI) is supplementary to its function. The GUI is a customization tool, not a core-feature.
- All of the data in the application is modifiable and used both in the GUI and Process. Therefore, every piece of data needs to be able to be viewed from a GUI, serialized, and used in its most basic format.
