Explicación detallada de VO, DTO, DO, PO en java

concepto

• VO (Ver objeto): objeto de vista, utilizado para la capa de visualización, su función es encapsular todos los datos de una página (o componente) especificada.

• DTO (objeto de transferencia de datos): el concepto de objeto de transferencia de datos se deriva del patrón de diseño J2EE. El propósito original es proporcionar entidades de datos de grano grueso para aplicaciones distribuidas EJB para reducir el número de llamadas distribuidas, aumentando así las llamadas distribuidas. y reducir la carga de la red, pero aquí me refiero al objeto de transmisión de datos entre la capa de visualización y la capa de servicio.

• DO (Objeto de dominio): Un objeto de dominio es una entidad comercial tangible o intangible extraída del mundo real.

• PO (objeto persistente): objeto persistente, que forma una relación de mapeo uno a uno con la estructura de datos de la capa de persistencia (generalmente una base de datos relacional). Si la capa de persistencia es una base de datos relacional, entonces cada campo en la tabla de datos (O varios) corresponde a uno (o varios) atributos de PO.

 

modelo

El siguiente es un diagrama de secuencia para establecer un modelo simple para describir la posición de los objetos anteriores en la aplicación de arquitectura de tres niveles.

• El usuario realiza una solicitud (tal vez para completar un formulario) y los datos del formulario se comparan como VO en la capa de presentación.

• La capa de presentación convierte el VO en el DTO requerido por el método correspondiente de la capa de servicio y lo transmite a la capa de servicio.

• La capa de servicio primero construye (o reconstruye) un DO basándose en los datos del DTO y llama al método comercial del DO para completar el negocio específico.

• La capa de servicio convierte el DO en el PO correspondiente a la capa de persistencia (la herramienta ORM se puede utilizar o no), llama al método de persistencia de la capa de persistencia, le pasa el PO y completa la operación de persistencia.

• Para una operación inversa, como la lectura de datos, también se convierte y se transmite de manera similar, se omite.

 

La diferencia entre VO y DTO

Quizás tengas una pregunta (en los proyectos en los que participé, muchos programadores tienen las mismas dudas): Dado que DTO es el objeto que transmite datos entre la capa de presentación y la capa de servicio, ¿por qué necesitas un VO?

¡Correcto! Para la mayoría de los escenarios de aplicación, los valores de atributo de DTO y VO son básicamente los mismos, y generalmente son POJO, por lo que no es necesario hacer esto, pero no olvide que este es un pensamiento a nivel de implementación. Para el nivel de diseño, el concepto todavía debe haber VO y DTO, porque hay una diferencia esencial entre los dos. DTO representa los datos que la capa de servicio necesita para recibir y devolver datos, y VO representa los datos que necesita la capa de visualización. para mostrar.

Puede ser más fácil de entender con un ejemplo: por ejemplo, la capa de servicio tiene un método getUser para devolver un usuario del sistema, uno de los cuales es género (género). Para la capa de servicio, solo se define semánticamente: 1-male, 2-mujer, 0-sin especificar, y para la capa de visualización, es posible que deba usar "chico guapo" para representar a los hombres, "bellezas" para representar a las mujeres y "secretos" para representar sin especificar. Hablando de esto, aún puedes refutarlo ¿No es suficiente con volver al "chico guapo y chica hermosa" en el nivel de servicio?

Para la mayoría de las aplicaciones, esto no es un problema, pero imagine que si los requisitos permiten a los clientes personalizar el estilo, y diferentes estilos tienen diferentes formas de expresar "género", o el servicio es utilizado por varios clientes al mismo tiempo (diferentes portales ), y diferentes clientes tienen diferentes requisitos para la capa de presentación, por lo que el problema está llegando. Además, volviendo al análisis a nivel de diseño, desde la perspectiva del principio de responsabilidad única, la capa de servicio solo es responsable del negocio y no tiene nada que ver con la forma específica de expresión. Por lo tanto, el DTO devuelto por él no debe ir acompañado de la forma de expresión.

La teoría pertenece a la teoría. Después de todo, este sigue siendo el pensamiento del análisis y el diseño. ¿Es necesario hacer esto en el nivel de realización? Un enfoque único para todos a menudo no vale la pena, y analizaré inmediatamente cómo tomar la decisión correcta en la aplicación.

 

Aplicación de VO y DTO

Lo anterior es solo un ejemplo simple para ilustrar la diferencia conceptual entre VO y DTO. Esta sección le dirá cómo tomar la decisión correcta en la aplicación.

En los siguientes escenarios, podemos considerar combinar VO y DTO en uno (nota: en el nivel de implementación):

• Los requisitos son muy claros y estables, y cuando el cliente tiene claro que solo hay uno, no es necesario distinguir entre VO y DTO. En este momento, VO se puede retirar y solo se puede usar un DTO. Por qué es VO retirado en lugar de DTO? Volviendo al nivel de diseño, las responsabilidades de la capa de servicio no deben combinarse con la capa de presentación. Por lo tanto, para el ejemplo anterior, puede comprender fácilmente que DTO todavía no puede usar "chico guapo y chica hermosa" para "género". Esto la conversión debe depender del script de la página (como JavaScript) u otros mecanismos (JSTL, EL, CSS)

• Incluso si el cliente se puede personalizar, o hay varios clientes diferentes, si el cliente puede usar una determinada tecnología (script u otro mecanismo) para lograr la conversión, también puede retirar VO

Los siguientes escenarios deben dar prioridad a la coexistencia de VO y DTO:

• Lo contrario de la escena anterior.

• Por algunas razones técnicas, por ejemplo, cuando un marco (como Flex) proporciona conversión automática de POJO a ciertos campos en la interfaz de usuario, puede considerar definir VO en el nivel de implementación. Esta compensación depende completamente de las capacidades de conversión automática de El marco La comparación entre la mejora de la eficiencia de desarrollo y mantenimiento y la disminución de la eficiencia de desarrollo y mantenimiento causada por el diseño de una VO más.

• Si aparece una "vista grande" en la página, y todos los datos que componen esta vista grande deben llamar a varios servicios y devolver varios DTO para ensamblar (por supuesto, esto también puede ser reemplazado por la capa de servicio que proporciona un DTO que devuelve un gran vista a la vez. Pero si es apropiado proporcionar un método de este tipo en la capa de servicio debe sopesarse a nivel de diseño).

 

La diferencia entre DTO y DO

La primera es la diferencia conceptual. DTO es el objeto de transmisión de datos entre la capa de presentación y la capa de servicio (se puede considerar como el acuerdo entre las dos), y DO es la abstracción de varios roles comerciales en el mundo real, lo que lleva a dos La diferencia en los datos entre usuarios, como UserInfo y User, para un método getUser, en esencia, nunca debe devolver la contraseña del usuario, por lo que UserInfo es al menos un dato de contraseña menos que User. En el diseño impulsado por dominios, como decía el primer artículo de la serie, DO no es un simple POJO, tiene una lógica empresarial de dominio.

 

Aplicación de DTO y DO

En el ejemplo de la sección anterior, los lectores cuidadosos pueden encontrar el problema: dado que la UserInfo devuelta por el método getUser no debe contener una contraseña, no debe haber una definición de atributo de contraseña, pero si también hay un método createUser, la UserInfo What ¿Qué debo hacer si necesito incluir la contraseña del usuario?

En el nivel de diseño, el DTO pasado por la capa de presentación a la capa de servicio y el DTO devuelto por la capa de servicio a la capa de presentación son conceptualmente diferentes, pero en el nivel de implementación, generalmente rara vez hacemos esto (defina dos UserInfo, o incluso más), debido a que esto no es necesariamente muy inteligente, podemos diseñar un DTO totalmente compatible, cuando la capa de servicio recibe datos, los atributos que no deben ser establecidos por la capa de visualización (como el precio total del pedido deben ser determinados por su precio unitario, cantidad, descuento No importa si la capa de visualización está configurada o no, la capa de servicio la ignorará, y cuando la capa de servicio devuelva datos, los atributos correspondientes no se establecerán para los datos que no deben devolverse (como contraseñas de usuario).

Para DO, hay un punto más que explicar: ¿Por qué no devolver DO directamente en la capa de servicio? Esto puede ahorrar el trabajo de conversión y codificación DTO, las razones son las siguientes:

• La diferencia esencial entre los dos puede llevar a una correspondencia uno a uno entre sí. Un DTO puede corresponder a múltiples DO, y viceversa, e incluso puede haber una relación de muchos a muchos entre los dos.

• DO tiene algunos datos que la capa de visualización no debería conocer.

• DO tiene un método comercial. Si pasa DO directamente a la capa de presentación, el código de la capa de presentación puede omitir la capa de servicio e invocar directamente operaciones a las que no debería acceder. Este es un problema para el mecanismo basado en AOP que intercepta el capa de servicio para el control de acceso.Es particularmente prominente, y el método comercial de llamar a DO en la capa de presentación también hará que la transacción sea difícil de controlar debido a problemas de transacción.

• Para algunos marcos ORM (como Hibernate), generalmente se usa la tecnología de "carga diferida". Si DO se expone directamente a la capa de presentación, en la mayoría de los casos, la capa de presentación no está dentro del alcance de la transacción (la sesión abierta a la vista es en la mayoría de los casos). Bajo las circunstancias no es un diseño digno de respeto), si intenta obtener un objeto asociado descargado cuando la sesión está cerrada, ocurrirá una excepción de tiempo de ejecución (LazyInitiliaztionException para Hibernate).

• Desde una perspectiva de diseño, la capa de presentación depende de la capa de servicio y la capa de servicio depende de la capa de dominio. Si se expone DO, la capa de presentación dependerá directamente de la capa de dominio. Aunque esta sigue siendo una dependencia unidireccional, este tipo de dependencia entre capas puede conducir a un acoplamiento innecesario.

Para DTO, hay un punto que debe explicarse, es decir, DTO debe ser un "objeto bidimensional plano". Tome un ejemplo para ilustrar: Si el Usuario está asociado con varias otras entidades (como Dirección, Cuenta, Región, etc.), luego getUser () ¿El UserInfo devuelto necesita devolver todos los DTO de sus objetos asociados?

Si este es el caso, inevitablemente conducirá a un aumento significativo en la cantidad de transmisión de datos. Para aplicaciones distribuidas, este diseño es aún más inaceptable debido a la transmisión, serialización y deserialización de datos en la red. Si getUser necesita devolver un AccountId, AccountName, RegionId, RegionName además de la información básica del usuario, defina estos atributos en UserInfo para "aplanar" un árbol de objetos "tridimensional" en un "plano" bidimensional objects ", el proyecto en el que estoy involucrado actualmente es un sistema distribuido. El sistema convierte todos los objetos asociados de un objeto en un árbol de objetos DTO de la misma estructura y lo devuelve independientemente del número de cosas. El rendimiento es muy lento. .

 

La diferencia entre DO y PO

En la mayoría de los casos, DO y PO tienen una correspondencia uno a uno. PO es un POJO que solo contiene métodos get / set. Sin embargo, algunos escenarios aún pueden reflejar la diferencia conceptual esencial entre los dos:

• DO no necesita persistir explícitamente en algunos escenarios. Por ejemplo, una estrategia de descuento de producto diseñada utilizando el patrón de estrategia derivará la interfaz de la estrategia de descuento y diferentes clases de implementación de la estrategia de descuento. Estas clases de implementación de la estrategia de descuento se pueden considerar como DO, pero ellos solo residen en la memoria estática y no es necesario persistir en la capa de persistencia, por lo que no existe un PO correspondiente para este tipo de DO.

• De la misma manera, en algunos escenarios, PO no tiene un DO correspondiente. Por ejemplo, hay una relación de muchos a muchos entre el profesor y el alumno. En una base de datos relacional, esta relación debe representarse como una tabla intermedia, que corresponde a un PO TeacherAndStudent. El PO, pero este PO no tiene un significado práctico en el campo empresarial, y no puede corresponder a ningún DO en absoluto. Debe indicarse específicamente aquí que no todas las relaciones de muchos a muchos no tienen significado comercial. Esto está relacionado con escenarios comerciales específicos. Por ejemplo, la relación entre dos OP afectará negocios específicos y existen múltiples tipos de tales relaciones. La relación de muchos a muchos también debe expresarse como un DO, otro ejemplo: hay una relación de muchos a muchos entre "función" y "recurso", y esta relación obviamente se expresará como un DO- "autoridad". .

• En algunos casos, para una determinada estrategia de persistencia o consideraciones de rendimiento, una OP puede corresponder a varios OD y viceversa. Por ejemplo, el cliente El cliente tiene su información de contacto Contactos. Aquí hay dos DO con una relación de uno a uno. Sin embargo, debido a consideraciones de rendimiento (casos extremos, como ejemplo), para reducir las operaciones de consulta de conexión de la base de datos, el cliente y los contactos son dos. Los datos de DO se combinan en una hoja de datos. Por el contrario, si un libro Libro tiene un atributo de portada, pero este atributo son datos binarios de una imagen, y ciertas operaciones de consulta no quieren cargar la portada juntas, reduciendo así la sobrecarga de E / S del disco y asumiendo un marco ORM Carga diferida en el nivel de atributo no es compatible, por lo que debe considerar separar la portada en una tabla de datos, a fin de formar un DO para hacer frente a una situación de orden de compra.

• Algunos valores de atributo de PO no tienen significado para DO. Estos valores de atributo pueden ser datos que existen para resolver ciertas estrategias de persistencia. Por ejemplo, para lograr un "bloqueo optimista", PO tiene un atributo de versión y esta versión es para DO No tiene ningún significado comercial y no debería existir en DO. De la misma manera, también puede haber atributos en DO que no necesitan persistir.

 

Aplicación de DO y PO

• Debido a que el marco ORM es muy poderoso y popular, y JavaEE también ha introducido la especificación JPA, básicamente no hay necesidad de distinguir entre DO y PO en el desarrollo actual de aplicaciones comerciales. PO se puede ocultar en DO a través de JPA, Hibernate Annotations / hbm. Aun así, hay algunas cuestiones a las que debemos prestar atención:

• Para los atributos que no necesitan persistir en DO, deben declararse explícitamente a través de ORM. Por ejemplo, en JPA, puede usar la declaración @Transient.

• Para los atributos que existen en PO para una determinada estrategia de persistencia, como la versión, debido a que DO y PO están fusionados, deben declararse en DO, pero debido a que este atributo no tiene un significado comercial para DO, el atributo debe ocultarse desde el exterior. ., El enfoque más común es privatizar el método get / set de la propiedad, o incluso no proporcionar el método get / set, pero para Hibernate, esto requiere una atención especial, porque Hibernate lee los datos de la base de datos y los convierte a DO. El mecanismo de reflexión primero llama al constructor de parámetros vacío de DO para construir una instancia de DO, y luego usa la especificación JavaBean para reflejar el método set para establecer el valor de cada atributo. Si el método set no se declara explícitamente o el método set está configurado a privado, hará que Hibernate no pueda inicializar DO, lo que resultará en una excepción de tiempo de ejecución.Un enfoque factible es establecer el método set de la propiedad en protected.

• Para escenarios en los que un DO corresponde a múltiples OC, o un OC corresponde a múltiples DO, y la carga diferida a nivel de atributo, Hibernate proporciona un buen soporte. Consulte la información relacionada de Hibnate.

Hasta ahora, creo que todos tienen una comprensión más clara de los conceptos, las diferencias y las aplicaciones prácticas de VO, DTO, DO y PO. A través del análisis detallado anterior, también podemos resumir un principio:

El nivel de análisis y diseño y el nivel de realización son niveles completamente separados. Incluso si el nivel de realización puede combinar dos conceptos completamente independientes en uno a través de algunos medios técnicos, en el nivel de análisis y diseño, todavía (al menos en nuestra mente) necesitamos Las cosas conceptualmente independientes se distinguen claramente Este principio es muy importante para un buen análisis y diseño (cuanto más avanzadas son las herramientas, más insensibles somos).