Capas en aplicacion Spring VS Java EE
He desarrollado en Java EE y Spring Boot.
como bien saben en gran variedad de empresas utilizas estas dos tecnologías,
Pero me surge una duda, que capas y tipos de clases pueden utilizarse en Ambas y cuales no?
Por ejemplo
En Java EE
En la capa de negocio he visto que utilizan el componente BO (Busines Object)
Mientras que en Spring Boot Service (@Service)
¿Es valido utilizar un MiClaseBO en Spring?
¿Es valido utilizar MiClaseService en Java EE?
Estas preguntas las hago por que últimamente he visto Service en Java EE y BO en Spring.
Me surge la duda de que tan valido sea utilizar estos componentes en las distintas tecnologías o es maña de los desarrolladores
de Java EE al pasarse a Spring seguir utilizando este tipo de componentes?
Por lo que entiendo ambos exponen Lógica de Negocio a la capa de Negocio.
ó se pueden usar ambos pero por ejemplo:
Controller invoca a Service
Service Invoca a DAO y BO
BO que tiene toda la logica de negocio.
¿Que tan buena practica puede ser esto?
Adicional he buscado paginas en la cuales mencionen los estándares de Spring así como la siguiente pagina muestra los de Java EE
¿Alguna pagina o libro que me recomienden para obtener mas información?
Saludos
- Inicie sesión o regístrese para enviar comentarios
Re: capas en aplicación
Aunque es un poco antiguo (2009), hay un libro de Microsoft que explica ese asunto de las capas, cuáles elegir, etc. Se llama Microsoft Application Architecture Guide, 2nd Edition y el dato se encuentra en el Capitulo 5, Layered Application Guidelines (PDF).
Por extraño que parezca, los libros más recientes de Microsoft (2017), que pueden consultarse en
~~~
En Spring
En Spring yo uso @Service para validar pametros de entrada de mi @Controller y @Component para las implementaciones de mis interfaces.
En JEE usaba los DAO que vendría siendo el equivalente de los @Repository de Spring.
Al final del día las buenas practicas y los patrones de diseño son recomendaciones por parte de un grupo de "expertos" que tratan de encontrar una solución común para un problema común, yo tomo en cuenta estas recomendaciones y las aplico según sea el caso:
1. Si le da simpleza al diseño, al codigo y a la solución en concreto que se me presenta, pues la implemento.
2. Si le mete complejidad la desecho.
Lo importante es tener código simple de leer, mantener y extender.
Al final son convensiones
Al final de cuentas solo son convensiones, mucho tiempo, por ejemplo yo use spring con hibernate para la persistencia y mis clases se llamaban DAOs.
En Spring esas anotaciones existen para diferencias las capas, tenemos servicios que exponen funcionalidad encapsulada, componentes que es la capa con logica de negocio y respositorios que al final es la capa de datos. Como los llames al final solo es la convencion, como lo mencionas en Java EE tenemos diferentes tipos de EJB que al final son BO que encapsulan el negocio, JPA para la persistencia, etc.
No te dejes ir tanto por como un framework nombra sus componentes, al final tenemos las tipicas capas, vista, logica y persistencia que cada framework por convension nombra de cierta forma, como lo mencionan en otro comentario, te recomendaria en estudiar patrones de diseño/arquitectura pata que tus aplicaciones se apeguen a esto y no seas uno mas de los que dice "pero asi se ase en el framework este".
Arquitectura EE vs Spring
Considero que ambos tienen sus peculiaridades, pero en general, están pensados para ofrecer simplicidad, performance y escalabilidad, personalmente, me siento a gusto con EE, pero hay algunas cosas que veo más rápido ejecutar con Spring, y es posible hacerlos convivir para explotar lo mejor de cada uno, siempre y cuando se respeten sus reglas y buenas prácticas.
Yo lo que hago es tener una capa de negocio para realizar mis procesos, sumas, restas, etc. y todas las demás capas no llevan nada de eso, los datos y objetos se pasan tal cual al negocio que es el encargado de "procesar" los datos en crudo y devolver al servicio la información lista para responder.