docs - spring form tags submit button
¿Cuándo es necesario o conveniente usar Spring o EJB3 o todos juntos? (2)
Estoy un poco confundido por el uso mixto de JSF2 + Spring + EJB3 o cualquier combinación de estos. Sé que una de las características principales de Spring es la inyección de dependencias, pero con los beans administrados JSF puedo usar @ManagedProperty @ManagedBean y @ManagedProperty y obtengo la funcionalidad de inyección de dependencias. Con EJB3 estoy aún más confundido acerca de cuándo usarlo junto con JSF o si incluso hay una razón para usarlo.
Entonces, ¿en qué tipo de situación sería una buena idea usar Spring + JSF2 o EJB3 + JSF2?
Hasta ahora, he creado solo algunas aplicaciones web pequeñas usando solo JSF2 y nunca tuve que usar Spring o EJB3. Sin embargo, veo en muchos lugares que la gente está trabajando con todas estas cosas juntas.
En primer lugar, Spring y EJB (+ JTA) son tecnologías que compiten entre sí y, por lo general, no deben usarse juntas en la misma aplicación. Elija el uno o el otro. Spring o EJB (+ JTA). No le diré cuál elegir, solo le contaré un poco de la historia y los hechos para que pueda tomar la decisión más fácilmente.
El problema principal que están tratando de resolver es proporcionar una API de capa de servicio empresarial con administración automática de transacciones. Imagine que necesita disparar múltiples consultas SQL para realizar una sola tarea empresarial (por ejemplo, hacer un pedido), y una de ellas falló, entonces, por supuesto, le gustaría que todo se retrotraiga, para que el DB se mantenga en el mismo estado como lo fue antes, como si no hubiera pasado nada. Si no hizo uso de las transacciones, entonces la base de datos quedaría en un estado no válido porque el primer grupo de consultas realmente tuvo éxito.
Si está familiarizado con JDBC básico, debe saber que esto se puede lograr desactivando la confirmación automática en la conexión, luego disparando esas consultas en secuencia, y luego ejecutando commit() en el mismo try en cuya catch (SQLException) a rollback() se realiza. Sin embargo, es bastante tedious implementarlo todo el tiempo.
Con Spring y EJB (+ JTA), una llamada al método de servicio de negocio individual (sin estado) cuenta por defecto de forma transparente como una única transacción completa. De esta forma, no necesita preocuparse por la gestión de transacciones en absoluto. No es necesario crear manualmente EntityManagerFactory , ni invocar explícitamente em.getTransaction().begin() y tal como lo haría cuando está em.getTransaction().begin() estrechamente la lógica del servicio empresarial en una clase de bean de respaldo JSF y / o están utilizando RESOURCE_LOCAL lugar de JTA en JPA. Por ejemplo, podría tener solo la siguiente clase EJB utilizando JPA:
@Stateless
public class OrderService {
@PersistenceContext
private EntityManager em;
@EJB
private ProductService productService;
public void placeOrder(Order newOrder) {
for (Product orderedproduct : newOrder.getProducts()) {
productService.updateQuantity(orderedproduct);
}
em.persist(newOrder);
}
}
Si tiene un @EJB private OrderService orderService; en su bean de respaldo JSF e invocar el orderService.placeOrder(newOrder); en el método de acción, se realizará una sola transacción completa. Si, por ejemplo, una de las llamadas updateQuantity() o la llamada updateQuantity() falla con una excepción, se revertirán las llamadas updateQuantity() y se dejará el DB en un estado limpio y nítido. Por supuesto, podría atrapar esa excepción en su bean de respaldo JSF y mostrar un mensaje de rostros más o menos.
Debe tenerse en cuenta que "Spring" es un marco bastante amplio que no solo compite con EJB, sino también con CDI y JPA. Anteriormente, durante las oscuras edades de J2EE, cuando EJB 2.x era extremadamente OrderService implementar (el ejemplo EJB 3.x OrderService anterior en EJB 2.x requeriría al menos 5 veces más código y algún código XML). Spring ofreció una alternativa mucho mejor que requería menos código Java (pero aún muchos códigos XML). J2EE / EJB2 aprendió las lecciones de Spring y vino con Java EE 5, que ofrece una nueva API EJB3 que es incluso más ingeniosa que Spring y no requiere XML en absoluto.
Spring también ofrece IoC / DI (inversión de control, inyección de dependencia) fuera de la caja. Esto fue durante la era J2EE configurada por XML, que puede ir bastante por la borda. Hoy en día, Spring también usa anotaciones, pero todavía se necesita algo de XML. Desde Java EE 6, después de haber aprendido las lecciones de Spring, se ofrece CDI para proporcionar la misma funcionalidad DI, pero sin necesidad de XML. Con Spring DI @Component / @Autowired y CDI @Named / @Inject puedes lograr lo mismo que JSF con @ManagedBean / @ManagedProperty , pero Spring DI y CDI ofrecen muchas más ventajas: puedes escribir interceptores para pre -proceso o creación de beans gestionada posterior al proceso / destroy o una llamada a método administrado de bean, puede crear ámbitos personalizados, productores y consumidores, puede inyectar una instancia de alcance más limitado en una instancia de alcance más amplio, etc.
Spring también ofrece MVC, que esencialmente compite con JSF. No tiene sentido mezclar JSF con Spring MVC. Further Spring también ofrece Data, que es esencialmente una capa de abstracción adicional sobre JPA, minimizando aún más el texto repetitivo de DAO (pero que esencialmente no representa la capa de servicio comercial como un todo).
Ver también:
No hay una respuesta fácil aquí, ya que Spring es muchas cosas.
En un nivel muy alto, Spring compite con Java EE, lo que significa que usaría cualquiera de ellos como un marco completo de pila.
En un nivel de grano más fino, el contenedor Spring IoC y Spring Beans compiten con la combinación de CDI y EJB en Java EE.
En cuanto a la capa web, Spring MVC compite con JSF. Algunos Spring xyzTemplate compite con las interfaces JPA (ambos pueden usar, por ejemplo, Hibernate como la implementación de los mismos).
Es posible mezclar y combinar; por ejemplo, use frijoles CDI y EJB con Spring MVC, O use Spring Beans con JSF.
Normalmente no usarás 2 técnicos competidores directamente. Spring beans + CDI + EJB en la misma aplicación, o Spring MVC + JSF es tonto.