DTOs e interfaces

Question

Recientemente me encontré con este patrón (?) En nuestro código y me pregunto cómo es útil, si es que lo hace. Tenemos una aplicación Spring y una interfaz Flex usando BlazeDS. Se decidió que utilizamos en nuestros interfaces de DTO, así:

Java

public interface ISomeDTO { 
     Integer setId(); 
     void getId(Integer i); 
} 

public class SomeDTO implements ISomeDTO 
{ 
.. 
} 

 

Actionscript

public interface ISomeDTO { 
     var id:Integer; 
} 

public class SomeDTO implements ISomeDTO 
{ 
.. 
} 

 

¿Qué una interfaz en un DTO ganas? Estos son objetos livianos con una lógica absolutamente nula. Los DTO tienen sentido, las interfaces tienen sentido, pero no juntas.

Answer 1

No veo por qué las interfaces y las DTO no funcionarían juntas.

Considere una fábrica/ensamblador que crea objetos de dominio de DTO. Puede configurar la fábrica con estrategias para que pueda crear implementaciones específicas de un objeto de dominio según el tipo de DTO que se le dé. El DTO idealmente se escribiría a una interfaz aquí. (Esto también funciona en la dirección opuesta).

No estoy diciendo que deba poner cada DTO detrás de una interfaz, pero al igual que con los objetos de dominio, sin duda habrá casos en los que sea beneficioso hacerlo.

Answer 2

En un entorno basado en transacción, los DTO se utilizan para dividir las entidades de base de datos de la sesión de base de datos subyacente.

Estas sesiones normalmente no están disponibles y la mayoría de las entidades están compuestas por proxies que cargan cargas perezosas de miembros. Por lo tanto, si tuviera acceso a una propiedad de colección en una entidad procesada, el proxy carga la colección en este punto en el tiempo, ya sea que exista o no una transacción en la base de datos. Por lo tanto, un acceso de un miembro de la entidad podría engendrar un error cuando no haya una transacción activa.

Exactamente esto sucede cuando reenvía sus entidades a la vista, que intenta acceder a un miembro. Dado que la gestión de transacciones normalmente se define en la capa de servicio, no hay ninguna transacción activa en la vista/controlador.

en dar la vuelta este problema existen diferentes enfoques:

• mantener la sesión abierta a través de, por ejemplo, un mecanismo de filtro (OpenSessionInViewFilter de primavera), aunque estrictamente hablando, esto es un anti-patrón
• deje que sus DAOs una devolución de objetos de transferencia de datos llenas de los miembros necesarios ya se ha inicializado

esperanza que esto ayudó.