Now that I have understood what a DTO is good for, I’m thinking about ways to improve it. As they are right now, our DTOs are POJOs extended by JSR 303 annotations for defining constraints on their fields/methods. The annotations are duplicates of the annotations defined on the corresponding entities.
Since I have worked with the UI code most of my time so far, I have felt the drawback of not having JavaFX properties in our DTOs: they cannot be observed easily by the GUI controls. There is a wrapping mechanism to add this observability, but it is rather complicated to use and requires a lot of extra code.
So why not make the DTOs full JavaFX beans? After all, we would not be the first project to do this. Two common objections were raised when I brought this up:
- DTOs are created on the server which should not have dependencies to a GUI/client technology.
- We would need to mix JavaFX beans with JSR 303 annotations.
Let’s address the first point. Yes, having a GUI dependency in your server code is not a good idea. But are JavaFX properties a GUI technology? Or even a client technology? It’s a bit unfortunate that they were introduced as part of JavaFX in a
javafx.* package such that everyone identifies them as a GUI technology at first sight. It’s an image problem. I would argue they are a self-contained technology which is independent of any GUI parts of JavaFX and could therefore be used for any data model, no matter if it’s on the client, on the server, or shared between both. Even if one does not use JavaFX for the frontend, depending on JavaFX properties would do almost no harm in practice since JavaFX is part of the JDK and your server code certainly depends on the JDK. So the no client dependencies on the server argument is merely a formal one in my opinion.
What about the second point, mixing JavaFX properties with bean validation annotations? I have never tried it myself, but I have the feeling it cannot be that big of a problem. If it works in the FXForm2 demo, why should there be a fundamental incompatibility between these two technologies? But I admit that a good prototype is needed to make a final judgment.
We will have a meeting on this tomorrow. Let’s see what the others think.