Arquitectura JSF-SPRING-HIBERNATE- Buenas prácticas relacionadas con los beans

Question

Estoy desarrollando un proyecto web y después de mucha investigación he decidido seguir adelante con JSF + Primefaces, Spring e Hibernate. Si bien el diseño de la arquitectura de mi proyecto he finalizado el siguiente enfoque:

Actor -> página JSF + PrimeFaces ---> Copia de frijol -> Servicio de frijol -> Dao -> Hibernate

• Service Bean y DAO son beans de primavera con inyección de dependencia.

Mi preocupación ahora es ahora con respecto al bean de respaldo: Voy a utilizar múltiples beans de respaldo para la página de interfaz de usuario, dependiendo del tipo de página que necesito para rendir.

Ahora, por ejemplo, para una nueva página de registro de usuario tengo UserProfile.xhtml que usa UserBackingBean. UserBackingBean tiene UserServiceBean inyectado por la primavera. UserServiceBean tiene Userdant inyectado por Spring.

Ahora en UserBackingBean cuando el usuario ingrese los datos del formulario de UserProfile.xhtml tendré que rellenar el objeto User.java domain (ORM).

a) ¿Cuál es la mejor práctica para esto? ¿Debo iniciar el User.java en el constructor en UserBackingBean? ¿Es este el enfoque adecuado? Por favor, sugiera si hay alguna otra salida?

b) ¿También sugiera por favor sobre la arquitectura antedicha que he decidido para mi proyecto? ¿Es el enfoque adecuado?

Answer 1

La regla general que sigo es que los límites de las transacciones están marcados en los beans de servicio, por lo tanto, no me gusta modificar el hypenate POJO fuera de un servicio porque no sé si ya hay una transacción ejecutándose. Así que desde el bean de respaldo llamaría a la capa de servicio pasar los parámetros que la capa de servicio necesita para construir el pojo de hibernación y guardarlo, actualizarlo, ... etc.

Otra forma de hacerlo sería tener su bean de respaldo implementa una interfaz definida por la capa de servicio y luego pasa el bean de respaldo a la capa de servicio. Por ejemplo.

public interface UserInfoRequest { 
    public String getName(); 
} 


@Service 
public class SomeSpringService { 

    @Transactional(.....) 
    public void registerNewUser(UserInfoRequest request) 
    { 

    } 

} 

public class SomeBackingBean implements UserInfoRequest { 

    private SomeService someSpringService; 

    public void someMethodBoundToSJF() 
    { 
     this.someSpringService.registerNewUser(this); 
    } 
} 

En cuanto a su última pregunta que no soy un fan de JSF, creo que JSF es fundamentalmente errónea porque es un marco basado en componentes de servidor. Por lo tanto, mi argumento contra JSF es un argumento genérico contra los marcos basados ​​en componentes del lado del servidor.

La falla principal con los marcos basados ​​en componentes del lado del servidor es que no se controla el resultado del componente, lo que significa que está atascado con el aspecto del componente; si desea algo diferente, debe escribir el suyo componente o tienes que modificar un componente existente. Los navegadores web están evolucionando muy rápidamente y agregan nuevas características que realmente pueden mejorar la calidad de la interfaz de usuario de una aplicación, pero para ti esas características tienes que escribir HTML, CSS y JavaScript directamente y los componentes del servidor lo hacen más difícil.

Las arquitecturas de componentes del lado del cliente están aquí y son mucho mejores que hacer componentes en el lado del servidor. Aquí está mi pila de recomendaciones.

del lado del cliente Arquitectura:

• jQuery.JS - libary básica para hacer todos los navegadores tienen el mismo aspecto de JavaScript
• Backbone.js + underscore.js - arquitectura basada en componentes de cliente de alto nivel
• handlebars.js - para las plantillas del lado del cliente
• Twitter arranque - a dan un plato decente conjunto de widgets de CSS &

se escribe código en HTML, CSS y JavaScript organizado de la columna vertebral que hablan vistas al servidor modelos usando AJAX. Usted tiene control total sobre la experiencia del usuario del lado del cliente con suficiente estructura para realmente hacer un buen código reutilizable.

Arquitectura del servidor Lado:

• anotación Driven Spring MVC, servicios y Dao (@Controller, @Service, @Repository) de exploración componente
• primavera con autowiring por tipo (@Autowired, @Inject)
• AspectJ el tiempo de carga de tejer o Tiempo de Compilación Weaving
• Hibernate
• Tomcat 7
• JSP como el punto de vista técnico gía para Spring MVC (sí cluncuky pero usted no estará creando demasiadas páginas JSP, sobre todo para usng <% @inculde> Directiva

Herramientas: - Primavera conjunto de herramientas - JRebel (de modo que usted don' tengo que iniciar y detener el servidor) realmente funciona realmente vale la pena el dinero - Tomcat 7