DTO et interfaces

Question

J'ai récemment parcouru ce modèle (?) Dans notre code et je me demande comment c'est utile, voire pas du tout. Nous avons une application Spring et une interface Flex en utilisant BlazeDS. Il a été décidé que nous utilisons sur nos interfaces DTO, comme ceci:

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'est-ce une interface sur un DTO gagner? Ce sont des objets légers avec une logique absolument nulle. Les DTO ont du sens, les interfaces ont un sens, mais pas ensemble.

Answer 1

Je ne vois pas pourquoi les interfaces et les DTO ne fonctionneraient pas ensemble. Considérez un fabricant/assembleur qui crée des objets de domaine à partir de DTO. Vous pouvez configurer l'usine avec des stratégies afin qu'elle soit capable de créer des implémentations spécifiques d'un objet de domaine en fonction du type de DTO qui lui est donné. Le DTO serait idéalement tapé à une interface ici. (Cela fonctionne aussi dans la direction opposée). Je ne dis pas que vous devriez mettre chaque DTO derrière une interface, mais tout comme avec les objets de domaine, il y aura certainement des cas où il est avantageux de le faire.

Answer 2

Dans un environnement basé sur les transactions, les DTO sont utilisés pour séparer vos entités de base de données de la session db sous-jacente.

Ces sessions sont normalement indisponibles et la plupart des entités sont constituées de proxys qui chargent paresseusement des collections de membres. Ainsi, si vous accédiez à une propriété de collection sur une entité mandatée, le proxy charge la collection à ce stade, qu'il existe ou non une transaction de base de données. Ainsi, un accès d'un membre d'entité peut générer une erreur lorsqu'il n'y a pas de transaction active. Cela se produit exactement lorsque vous transférez vos entités à la vue qui tente d'accéder à un membre. Comme la gestion des transactions est normalement définie dans la couche de service, il n'y a pas de transaction active dans la vue/le contrôleur.

Pour ce problème, il circumnavigation existe différentes approches:

• Conserver la session ouverte par exemple un mécanisme de filtre (OpenSessionInViewFilter de printemps), bien que strictement parlant ceci est un anti-modèle
• laissez vos OTI retourner un objets de transfert de données remplis avec les membres nécessaires déjà initialisé

espoir que cela a aidé.