JavaFX: la forma correcta de usar Propiedades con objetos de dominio

JavaFX ha proporcionado un montón de nuevos objetos de Propiedad, como los javafx.beans.property.DoublePropertyque le permiten definir campos que pueden observarse y sincronizarse automáticamente.

En muchos ejemplos de JFX, la clase de modelo MVC tiene varios de estos campos de Propiedades, que luego pueden vincularse automáticamente a la vista.

Sin embargo, esto parece alentarnos a poner propiedades JFX en nuestros objetos de dominio (si supone que la clase Modelo va a ser un objeto de dominio), lo que me parece una separación deficiente de las preocupaciones (es decir, poner el código GUI en el dominio )

¿Alguien ha visto resolver este problema en la "vida real" y, de ser así, cómo se hizo?

He estado jugando con JavaFX 2.0, por lo que supongo que se trata tu pregunta. No es un código de producción real, solo un proyecto personal, pero me encontré con el mismo problema que mencionaste anteriormente. Todo el modelo tiende a volverse dependiente del marco 2D, y no me gusta.

Lo que hice fue dividir cada clase del modelo en dos, la clase de modelo real , que tiene la capacidad de cargar su contenido desde la base de datos, sabe cómo altera su estado, etc., etc. y la clase de representación que decide la apariencia. en la pantalla. Este último contendría todas las clases de propiedad.

Encontrarás el mismo diseño en cualquier marco MVC, como Swing. es solo que aquí no hay escapatoria para hacerlo.

Casi 7 años después y esta pregunta sigue siendo tan válida como antes.

En mi opinión, javafx nunca debe ser importado por ninguna de las clases que pertenecen al Modelo. Sin embargo, pueden funcionar muy bien si adoptas un MVVM combinado con la arquitectura MVC. En este sentido, el

• entidades = (dominio) modelo ( M )
• Archivos FXML = ver ( V )
• el controlador sigue siendo el controlador ( C )
• el modelo de vista ( VM ) = un nuevo conjunto de clases de datos que solo contienen propiedades javafx y una referencia al objeto de dominio real (M) que representa. Puede pasar llamadas de método de lógica de negocios más adelante a este objeto, actuando como un compuesto / decorador.

Otra forma de ver las cosas es pensar en la clase de controlador como parte de la vista, ya que todo lo que hace es vincular el modelo de vista con la vista (datos y acciones). Por lo tanto, podría llamarse fácilmente Presentador o incluso Binder. Sin embargo, esto depende de cómo utilice el controlador. Si agrega lógica para manipular el modelo de vista en la clase Controller, entonces merece su nombre y tiene la arquitectura presentada anteriormente. Si la clase de controlador solo une datos del modelo a elementos de la interfaz de usuario y ActionEvents a los métodos del modelo, entonces tiende a tener la arquitectura mutante MVVM que se presenta a continuación.

Creo que estas arquitecturas de alguna manera coinciden con las ideas del tío Bob sobre arquitectura limpia (la capa de presentación).