Vaadin: Patrones de diseño

Question

Actualmente estoy trabajando en tres aplicaciones de Vaadin y realmente siento que extraño algo. Solía ​​trabajar con Spring MVC anteriormente, donde la arquitectura es clara y está desacoplada, se inyectan servicios a los controladores y no se empareja el controlador con la IU, etc.

Ahora en Vaadin esa es una historia diferente. Así que si hay algún especialistas vaadin por ahí, déjame hacerte algunas preguntas:

Pregunta 1:

• ¿Está bien para inyectar servicios (o DAO) directamente a los componentes de interfaz de usuario?
• Ejemplo: El componente responsable de mostrar los contactos en la aplicación de correo electrónico (ContactWidget, basado en VerticalLayout with Links) necesita mostrar los contactos. ¿Está bien inyectar contactRepository directamente a este elemento de UI?

Pregunta 2: se está pasando

• referencia a la aplicación principal a la enorme cantidad de componenets de interfaz de usuario, ya que muchos de los componentes de interfaz de usuario necesita acceder a algunos datos globales o invocar métodos globales sobre principal clase de aplicación
• Ejemplo: El componente emergente tiene un botón que abre una nueva ventana, que debe ser hija de la ventana principal de la aplicación. Por lo tanto, el componente emergente debe tener referencia a la aplicación principal.

Pregunta 3:

• Las dependencias entre los componentes de interfaz de usuario puede ser bastante salvaje. Probablemente no hay mucho que hacer aquí, pero a veces no parece que esta ventana depende de esta lista que depende de esa ventana emergente ... se entiende, se ve muy bien acoplado a mí

I'd me gustaría aprender todo lo posible sobre un buen diseño con Vaadin antes de que mi código cambie a Spaghetti, por lo que cualquier sugerencia, experiencia y mejores prácticas serían apreciadas.

Answer 1

Hemos tenido mucha suerte usando el patrón MVVM (también conocido como Fowler's PresentationModel). Sus documentos son un poco viejos, pero es un buen punto de partida.

Después de leer eso, mis respuestas pueden tener más sentido

1. Nº Inyectar sus servicios en su modelo de vista. El ViewModel será una Fachada (y puede encapsular adaptadores, decoradores, cachés y cualquier otro patrón que usted decida que necesita)

2. No vi una pregunta aquí, pero tenemos una situación similar a la que tiene describiendo Usamos el EventBus de Guava para comunicarnos entre componentes desacoplados.De esta forma, si necesita abrir una nueva ventana, puede: eventBus.post(new NewWindowRequest(theComponent)) Y su aplicación principal puede suscribirse al mismo evento, y luego abrir la ventana.

3. MVVM y el uso prudente de EventBus pueden ayudar. Además, Vaadin's BeanItem y ObjectProperty se pueden usar para propagar cambios, ya que son parte del patrón incorporado de observador/enlace de datos de Vaadin.

Hace poco hice un presentation on MVC vs MVP vs MVVM. El código de ejemplo puede ayudarlo a comprender el cambio de MVC a MVVM. Está escrito en JavaScript, pero es lo suficientemente simple como para creer que la mayoría puede seguirlo. Agradezco cualquier comentario que pueda tener.

Answer 2

Vaadin es una gran pieza de software y definitivamente no debe terminar con el código Spaghetti. De todos modos, todo depende de ti.

Respuesta 1

No, no lo es. El acoplamiento cerrado es malo independientemente del marco que se utilice. Su ejemplo (ContactWidget) describe una implementación personalizada de una lista. Se puede representar como una tabla con o sin información adicional. Usaré el ejemplo de tabla porque también es más complejo y más flexible (puede construir una aplicación completa con un componente de tabla avanzado y un enlace de datos adecuado).

Vaadin define el modelo de datos avanzado siguiendo el conocido patrón MVC. Hay tres capas anidadas: contenedor, elemento, propiedad (los visores de propiedades y los editores también están definidos). El libro de Vaadin sugiere una buena analogía: aplicación de hoja de cálculo. Así que el contenedor, el artículo y la propiedad corresponderán a la tabla, fila y celda. Fácil de imaginar, fácil de entender. Finalmente, ItemContainer revelará su naturaleza y comprenderá que este es el contrato clave para cualquier arquitectura buena y flexible basada en Vaadin. Yo sugeriría que mirar a través del libro Vaadin, para obtener todos los demás detalles:

• https://vaadin.com/book/-/page/datamodel.html
• https://vaadin.com/book/-/page/datamodel.container.html

También puede examinar la aplicación contenedor detrás de cualquier complemento PagedTable a mejorar todavía más la comprensión. Comience también con ArrayContainer https://vaadin.com/directory#addon/array-container, simplificará mucho para usted.

Respuesta 2

no parece ser una buena solución que pasa la referencia principal de la aplicación. Notaste que la instancia de la aplicación representa la sesión, pero será mucho mejor para ti definir algún tipo de contrato de SessionContext (que aún puede ser implementado por tu aplicación). Se puede definir un método estático para proporcionar acceso transparente a la instancia de SessionContext correspondiente. Debajo del capó puede usar ThreadLocal variable http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html de tal manera que se deshará de todos los parámetros parásitos que pasan.

Respuesta 3

Diseño de la jerarquía con un gran cuidado. No active el repintado usted mismo, use Refresher en su lugar. Vigila toda la arquitectura.

Finalmente, Vaadin es fácil de usar, así que no dude en hacer algunos pequeños PoC y demos antes de cambiar la base de código principal.

Como era sugerimos que también puede intentar MVVM https://vaadin.com/directory#addon/bambi-mvvm