java - que - spring mvc caracteristicas
¿Cómo utilizar la arquitectura en capas de Spring y seguir una estructura orientada a objetos? (4)
Creo que estás haciendo una pregunta incorrecta aquí. La arquitectura en capas no es inherentemente orientada a objetos, y por lo tanto, aunque usar (algunas de) las prácticas orientadas a objetos sea posible o incluso aconsejable, no debería ser el objetivo en sí mismo. Es como preguntar cómo utilizo las mejores prácticas de manejo de camiones para andar en bicicleta.
¿Por qué digo que la arquitectura en capas no está orientada a objetos? Bueno, como sabemos, hay tres principios que distinguen el diseño orientado a objetos: encapsulación, herencia y polimorfismo.
Mientras que los dos últimos pueden o no estar presentes, dependiendo de sus opciones de diseño, la arquitectura en capas es, en gran medida, lo opuesto a la encapsulación: por la naturaleza de este enfoque, se separan explícitamente sus datos ("DTO") de su lógica (" servicios").
No me malinterpretes, el hecho de que este enfoque no esté orientado a objetos no significa que haya algo malo en ello. Y viceversa, "orientado a objetos" no es sinónimo de "bueno", es una de las muchas herramientas en la caja de herramientas de un programador y, al igual que con cualquier otra herramienta, es más adecuado para resolver algunos problemas que otros.
La arquitectura en capas es un buen patrón de diseño, que puede usarse con éxito para resolver muchos problemas de ingeniería de la vida real. Tiene su propio conjunto de mejores prácticas que pueden y deben usarse, y si bien ese conjunto puede tener algunas intersecciones con su contraparte de OOP, los dos ciertamente no son equivalentes.
Aprendí la primavera y su estructura en capas (controlador, servicio y dao)
@Controller("userController")
@service("userService")
@Transactional( propagation = Propagation.REQUIRED, isolation = Isolation.DEFAULT, readOnly = true)
@Repository("userDAO")
Ahora estoy confundido, ¿cómo hago uso de buenas prácticas de OOPS (como this ) con estas estructuras en capas para hacer un gran proyecto (el mundo real tiene una lógica de negocios más compleja que las aplicaciones de ejemplo que generalmente se proporcionan)? También quiero usar estas transacciones de primavera y otras características proporcionadas por el marco. ¿Puede alguien ayudarme con esto o referirse al proyecto de código abierto que aclara mis dudas?
El diseño de la aplicación Spring y OOD no son mutuamente excluyentes.
La aplicación Spring típica (MVC) tiene la siguiente estructura:
- Una o más clases de
@Controller. Estos son los puntos de entrada de su aplicación. No deben contener ninguna lógica de negocio. A pesar del nombre, los identifico como la V en MVC ( Model-View-Controller ) - Una o más clases de
@Service. Aquí es donde desarrolla su lógica de negocio (BL). Uno de los beneficios de poner su BL aquí es que puede ser reutilizado por varios controladores (por@Controllerun@Controllery un@RestController). Ellos son los C en MVC. - Una o más clases de
@Repository, donde implementas tu capa de persistencia (base de datos, en memoria, lo que sea ...). Además, puede implementar un conjunto de clases de@Componentque describen los objetos de su dominio. Estos son los M en MVC. - Otras clases que no puede asignar en el patrón MVC, como
@Configuration,@ControllerAdvicey otras clases de configuración / administración de Spring.
Mientras diseña cada uno de estos objetos, puede seguir el enfoque OOD que desee.
En el ejemplo de OOD que mencionaste, diseñaría mi aplicación de esta manera:
- Una vista (
@Controller) para cada actor. - Un servicio
@Servicepara cada caso de uso - Un
@Repositoryy un@Componentpara cada clase de dominio
EDITAR: puedes encontrar un proyecto de ejemplo que escribí para la universidad here . Implementa lo que expliqué en los últimos tres puntos con una capa adicional (entre @Controller y @Service) porque había un requisito para minimizar las dependencias en la capa C. Los conceptos aún se aplican.
Está intentando comprender dos conceptos diferentes que pueden interoperar juntos.
Arquitectura en capas
La arquitectura de capas es uno de los estilos arquitectónicos de la industria. En esto tenemos capas separadas para hacer lógica específica. Ejemplo tenemos capa de presentación, capa de negocios y capa de servicio de datos. Esto se llama corte horizontal de la aplicación. Hay otros estilos arquitectónicos, como la arquitectura orientada a servicios / basada en componentes, donde la aplicación se divide verticalmente.
Supongamos que tiene proceso de reserva automatizado. Normalmente, si utiliza el diseño de arquitectura en capas (división horizontal), tenemos diferentes capas para realizar el trabajo requerido. Pero cuando se trata de la división vertical, identificamos diferentes entidades de la aplicación como Reservation, Customer Management, Fund Management. Implementaremos estos componentes y se comunicarán entre sí para crear nuestra aplicación de reserva. El punto a recordar aquí es que el componente interno puede seguir la misma arquitectura en capas.
Conceptos OOPS
Los conceptos OOPS le ayudan a diseñar la aplicación de forma orientada a objetos. Una vez que haya identificado el estilo de la arquitectura, debe implementar la aplicación de una manera extensible que se pueda mantener fácilmente. Por lo tanto, tienen diferentes metodologías de implementación. OOPS es uno de ellos. Sugiere algunos de los principios de diseño que le ayudan a implementar las aplicaciones de una mejor manera.
Ver SOLID
En pocas palabras
La arquitectura en capas solo facilitará la capacidad de mantenimiento y la consistencia del código cuando se vuelva enorme y complejo.
El hecho a recordar es que hacer un diseño de software adecuado antes de hacer la implementación.
- Encapsulación: la lógica de negocios específica para un modelo de dominio debe ir dentro de ella.
- Abstracción: segregue las interfaces según la agrupación de servicios mientras escribe la lógica de negocios común en la abstracción.
- Herencia: utilícela cuando redacte objetos de dominio.
- Polimorfismo: junto con la herencia cuando se desea cambiar la lógica empresarial de los modelos secundarios.
En detalle
A continuación, estoy haciendo mi mejor esfuerzo para proporcionar un ejemplo de una aplicación ERP para esta discusión. Espero que un ERP sea un proyecto lo suficientemente grande como para ver la complejidad de la lógica empresarial.
La siguiente descripción es para cualquier desarrollador que necesite una idea para entender y hacer uso de la estructura de proyectos en capas en Spring (o en cualquier otro marco).
Pero tenga en cuenta que estas no son reglas que deben seguirse sino las mejores prácticas que deben utilizarse. :)
1. Capa de acceso a datos - Objetos de modelo / dominioEsto contiene la asignación de tablas reales a las clases.
2. Capa de acceso a datos - RepositorioEn un ejemplo de ERP, aquí es donde obtiene los modelos:
CustomerOrder,CustomerOrderLineEsto también contiene la lógica encapsulada de los objetos de dominio secundarios y la lógica de dominio del yo. Por ejemplo, el
CustomerOrderLinees un hijo deCustomerOrder. El niño no puede existir sin el padre. Así que el padre tendrá el control total de la construcción de los hijos dentro de él. Es decir , encapsulación de la lógica de negocios. . es decir:Add CustomerOrderLine,RemoveCustomerOrderLine, etc. Y cuando se trata de la lógica del dominio propio,ApproveCustomerOrder,RejectCustomerOrder, etc.
Esto contiene nada más que un simple CRUD a la base de datos con SELECT, INSERT, UPDATE and DELETE SQLs . Puede usar el patrón de repositorio en Spring junto con Spring Data JPA .
Nota clave: no escriba ninguna lógica compleja en esta capa a menos que su lógica sea muy intensiva en datos
En ese caso, es posible que tenga que escribir una o más funciones para hacer declaraciones de consulta complejas. (Preferiblemente en JPQL )
En un ejemplo de ERP, este es el lugar donde escribe la lógica para
GetCustomerOrders,GetCustomerOrderByCustomer,GetCustomerOrderLines,GetOrderByStatusEn términos simples, esta capa define cómo se comunicará la aplicación con las entidades externas, como la base de datos.
3. Capa de servicio
Este es el lugar donde debe colocar su lógica de negocios compleja que involucró varios modelos de dominio desconectados (no secundarios) . Estos serán reutilizados en Controladores Web y Controladores API Rest.
Por lo tanto, para mantener la consistencia e implementar la seguridad , preferiría que toda la lógica de negocios, incluso la que estaba escrita en los modelos de dominio, se envuelva en esta capa.
En el ejemplo de ERP, este es el lugar donde se escribe la lógica o se ajusta la lógica que está escrita en el Modelo de dominio. Por ejemplo,
ListCustomerOrder,ApproveCustomerOrderLine,ReleaseCustomerOrder,ReleaseCustomerOrder, ...
En caso de que esta lógica se ejecute junto con otras lógicas modelo, entonces también se deben llamar en secuencia dentro de la capa de servicio. Por ejemplo.
Varios ejemplos sobre lógica de negocios compleja
Si desea crear una
Purchase Orderpara su proveedor, cuando se libere laCustomer OrderdelCustomer Order.
Luego, esto se puede hacer creando un servicio llamado SupplyChainService usando Spring AOP al CustomerOrderService.ReleaseCustomerOrder .
4. Controladores
Los controladores se pueden clasificar en dos, a saber: controladores web y controladores REST. No se debe implementar lógica de negocios en esta capa porque se puede requerir la misma lógica para llamar en la Web, así como en el nivel de API.
En el sistema ERP, este es el lugar donde escribirá el controlador para el formulario de pedido del cliente para ingresar datos y guardarlo para crear un nuevo pedido de cliente.
Este será el lugar donde también creará un controlador API como REST para crear el pedido del cliente a través de una aplicación móvil o desde un cliente de Windows.
Gracias a la comunidad SO que me mostró áreas que no cubrí en los principios de OOP en esta respuesta