design-patterns - research - how to add hashtags on instagram

Vaadin: Patrones de diseño (2)

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. Entonces, si hay especialistas de Vaadin, déjenme hacerle algunas preguntas:

Pregunta 1:

¿Está bien inyectar servicios (o DAO) directamente a los componentes de la 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:

La referencia a la aplicación principal se está transfiriendo a la ENORME cantidad de componentes UI, porque muchos componentes de la interfaz de usuario necesitan acceder a algunos datos globales o invocar métodos globales en la clase de aplicación principal.
Ejemplo : el componente emergente tiene un botón que abre una nueva ventana, que debería ser el elemento secundario 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 la interfaz de usuario pueden ser bastante salvajes. 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 unido a mí

Me gustaría aprender todo lo posible sobre el 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án apreciadas.

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

Después de haber leído eso, mis respuestas pueden tener más sentido

No. Inyecte sus servicios en su ViewModel. ViewModel será una fachada (y puede encapsular adaptadores, decoradores, cachés y cualquier otro patrón que usted decida que necesita)
No vi una pregunta aquí, pero tenemos una situación similar a la que describes. 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.
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 una presentación sobre 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.

Vaadin es una gran pieza de software y definitivamente no debes 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. Sugeriría consultar el libro de Vaadin para obtener todos los demás detalles:

También puede revisar la implementación del contenedor detrás de cualquier complemento de PagedTable para obtener una mejor comprensión. Comience también con ArrayContainer https://vaadin.com/directory#addon/array-container , simplificará mucho para usted.

Respuesta 2

Pasar referencia a la aplicación principal no parece ser una buena solució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 la variable ThreadLocal http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html De esta forma se librará de todos los parámetros parásitos que pasen.

Respuesta 3

Diseña tu jerarquía con mucho cuidado. No active el repintado usted mismo, use Refresher lugar. Vigila toda la arquitectura.

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

Como se sugirió, también puedes probar MVVM https://vaadin.com/directory#addon/bambi-mvvm