Está utilizando objetos de transferencia de datos en ejb3 considerada como la mejor práctica

Question

Aunque obviamente no todos los escenarios pueden cubrirse con un solo diseño, generalmente se piensa que las clases ORM deben pasar de la presentación a la capa comercial (local o remoto), reemplazando la necesidad de objetos de transferencia de datos? Por lo que puedo ver, el uso de clases ORM presenta problemas de carga ansiosa e innecesaria, problemas de gestión de contexto y acoplamiento ajustado, pero también ahorra una gran cantidad de tiempo y mantiene las cosas simples. ¿Existe ahora un enfoque estándar que generalmente favorece a uno sobre el otro (para la mayoría de las situaciones)?

Answer 1

Esta es una pregunta muy interesante y he estado investigando y experimentando durante los dos años.

Creo que realmente no hay una respuesta correcta o incorrecta aquí. No creo que pueda decir simplemente que quiero uno sobre el otro porque, por lo general, es posible que desee un híbrido según cuáles sean sus clientes (página web, ws, máquina y/o local, remoto).

Lo importante que debe recordar aquí es cuáles son los pros y los contras de cada oferta y aplicar esto en función de sus requisitos.

Por ejemplo:

• Si estaba utilizando la SEAM, entonces usted podría querer evitar una arquitectura en capas en gran medida debido a que tiene acceso a un contexto de persistencia extendido. Otras tecnologías web sin este soporte tienden a funcionar mejor con un DTO que preparó el estado por adelantado.
• Si está enviando un mensaje remoto, lo importante es mantenerlo delgado y liviano, por lo general, un DTO funcionaría mejor aquí que un objeto de dominio enriquecido. Aquí puede suprimir de forma transparente cualquier problema/comportamiento de ORM.
• El patrón DTO tiene la ventaja de proteger a sus clientes de los cambios de dominio. Esto es particularmente importante si su aplicación es un servicio web, tener un objeto de dominio (entidad) que define su contrato podría dejarlo desatascado en algún momento.

Al envolver su sistema en capas y exponerlo y asegurarlo cuidadosamente, puede producir varias API para muchos clientes de diferentes tipos.

Answer 2

Creo que la existencia de DTO está relacionada con JPA/Hibernate defectos. Si siempre puedes hacer una inicialización transparente y perezosa, nunca los usarás. Entonces, usar DTO es un contrato donde mi dominio/espacio de trabajo siempre pierde (duplicación en todas partes). En resumen, puede usarlos pero tiene que odiarlos :)

Answer 3

¿Acoplamiento firme? Por favor explique.

En cuanto a mí DTO es un Anti-Patrón. EJB3 nos permite omitir su uso. Puede forzar su inicialización lenta antes de enviar Entity al cliente.

Por supuesto, si solo necesita dos de los 30 campos para enviar a un cliente, simplemente envíelos. Pero si todo el tiempo está copiado como en mi proyecto actual, trate de deshacerse de ese DTO. No veo ninguna razón para usarlos. Envía un objeto comercial al cliente como un cliente le preguntó. ¿Por qué usar wrapper?

Answer 4

Estoy de acuerdo con el último "altavoz" ¿por qué usar un contenedor cuando en ejb3 ?? Construimos un sistema bastante complejo sin DTO pero usando Entidades (JPA) funcionó find. Estaba claro ...

Answer 5

funcionaría solo con las entidades estaría bien si el controlador de la GUI envía propiedades del objeto a los formularios y no a los objetos de la entidad.Por otro lado, si se usan entidades y estas entidades tienen relaciones de muchos a uno, entonces uno debería esperar ver algunas desagradables excepciones, si el administrador de entidades no busca con entusiasmo las entidades.

Estas situaciones se pueden observar al intentar rellenar etiquetas de Spring MVC, por ejemplo, o construcciones similares de otros componentes de la GUI.

Además, dtos son un muy buen lugar para colocar anotaciones adicionales, tales como anotaciones de validación o JAXB, etc

Answer 6

Tengo varios temas contra el uso de entidades en la capa de presentación:

• Lock-in: Esto finalmente crea un estrecho vínculo entre su presentación y modelo. Resulta costoso cambiar cualquiera, en proyectos grandes, incluso imposible. Las herramientas modernas todavía no están allí.

• Seguridad: con los objetos modelo, puede transferir fácilmente varias informaciones de identificación de base de datos a sus páginas web. Este es un claro problema de seguridad. Usando dto:s puede ocultar estos en el servidor con mapas de sesión muy simples.

• Diferencia de necesidades: Las vistas de GUI rara vez son listas directas de objetos modelo. Más a menudo son algo más, bestias combinadas, guish. Las necesidades de la GUI tienden a infiltrarse en su modelo oscureciéndolo.

• Velocidad: Con las entidades, cada campo se procesa cada vez que las lee/escribe. Como los está pasando directamente a la capa de presentación, le resulta difícil intentar optimizar sus JPA (consultas), algo casi imposible. Definitivamente voy a volver a dirigir el acceso JDBC, como myBatis en futuros proyectos. Así eliminando ORM.

que tienen una serie de cuestiones en contra DTO:s también:

• DAO código extra.

A fin de cuentas, voy a votar por usar dto:s para todos los proyectos, eliminando JPA también. Por lo tanto, mi pila se convierte en algo así como:

• mybatis para el acceso a la base de datos
• POJO como DTO: s
• sin estado EJB por mis servicios DAO.
• StatefulEJB para backend GUI.
• JSF para la presentación.