DTO ou modèle de domaine objet dans la couche View?

Question

Je sais que c'est probablement une sempiternelle question, mais quelle est la meilleure pratique? L'utilisation d'un objet modèle de domaine dans toutes les couches de votre application, et même lier des valeurs directement à eux sur la JSP (j'utilise JSF). Ou convertir un objet modèle de domaine dans un DTO dans la couche DAO ou service et envoyer un DTO léger à la couche de présentation.

On me dit qu'il n'a pas de sens d'utiliser DTO parce que les changements à la base de données entraîneront des changements à tous vos DTO alors que l'utilisation des objets du modèle partout va simplement exiger des modifications de l'objet modèle concerné. Cependant, la facilité d'utilisation et la nature légère de DTO semble l'emporter que.

Je tiens à souligner que mon application utilise Hibernate modèle objets et utilise ses propres objets modèle créé sur mesure (ce qui signifie pas lié à une session DB, toujours détaché). Est-ce ou l'autre des scénarios ci-dessus plus bénéfique à un modèle strict modèle d'objet? L'utilisation Hibernate a été un énorme PITA en ce qui concerne des choses comme des exceptions Lazy Initialisation.

Je suis l'édition de cette question dans l'espoir de faire avancer la discussion (ne sais pas si je fais ce droit):

Le problème que j'ai avec des objets du modèle est qu'ils ne sont pas flexibles du tout. Un commentaire ci-dessous dit que l'application doit être conçue de telle sorte que les objets du modèle peuvent être utilisés dans toutes les couches. Pourquoi? Si un utilisateur veut un morceau de fonctionnalité ridicule, que je devais leur dire, «bien que ne fonctionnera pas avec les objets du modèle?

Clair et simple, il y a des moments où les objets juste modèle ne fonctionnera pas. Vous pouvez avoir:

public class Teacher {
    List<Student> students;
    [tons of other Teacher-related fields]
}
public class Student {
    double gpa;
   [tons of other Student-related fields]
}

mais peut-être que vous n'avez pas besoin toutes les informations. Vous avez juste besoin le nom de l'enseignant, le nombre d'étudiants est qu'ils enseignent cette année, et GPA moyenne pour tous les étudiants combinés. Que feriez-vous dans ce cas? Récupérer les informations complètes des enseignants et des relations étudiants et votre code devient un compte sur la Liste des élèves, puis calcule une moyenne totale de tous GPAs à l'intérieur? Cela semble waaaay plus d'efforts que la simple création d'un DTO avec 'chaîne lastName', 'int numStudents', et « double combinedGpa;

Il peut sembler que mon esprit a été fait sur ceux-ci, mais je dois encore travailler dans une application où les objets du modèle peuvent être complètement utilisés proprement dans tous les cas. L'application régulière du monde réel avec des hors du commun utilisateur demande ne fonctionnent pas de cette façon.

Answer 1

Cela dépend vraiment de la complexité de votre application. Le mélange des objets de domaine dans la couche de vue a deux conséquences possibles:

1. Vous serez tenté de modifier votre objet de domaine pour accueillir les choses dont vous avez besoin dans la couche de vue
2. Votre couche Voir contiendra la complexité supplémentaire causé par un décalage entre ce que vos objets de domaine et offrent ce que vous pensez vraiment besoin. Vous pourriez ne pas être en mesure de contourner cette complexité, mais il n'a probablement pas sa place dans la couche de vue.

Si vos objets de domaine sont simples et vos points de vue sont peu nombreux, en sautant les DTO est peut-être la chose la plus simple.

D'autre part, si votre modèle de domaine est susceptible d'évoluer et de devenir complexe et si vos points de vue sont susceptibles d'être nombreuses et variées, ayant des objets spécifiques de vue peut-être une bonne idée. Dans le monde MVC, en utilisant ViewModels est commun et fait beaucoup de sens pour moi.

Answer 2

Un autre vote pour les objets domaine. En ce qui concerne le domaine de conception Driven concerne le modèle de domaine est le roi et doit être utilisé si possible. L'application doit être conçue d'une manière où la plupart des couches (barre de couche d'infrastructure) peuvent utiliser des objets de domaine.

Je pense à DTO aussi utiles que si besoin d'être sérialisé les objets. S'il n'y a pas de transfert sur le fil ou dans une architecture incompatible je ne les utilise pas. modèle DTO est utile pour garder la sérialisation de l'objet de domaine. Considérant que l'interface utilisateur / interaction domaine ne sérialisation pas besoin, rester simple et utiliser les objets réels.

Answer 3

Je pense avoir DTO est généralement pas un motif contre. Il y a beaucoup de gens et les systèmes qui les utilisent et les avantages que vous obtenez est la couche de vue découplé qui peut être conçu et modularisé indépendamment du modèle de domaine. Bien que je suis d'accord que vous devez utiliser des objets de domaine si possible il y a des scénarios où vous pouvez obtenir des problèmes lorsque vous liez la couche de vue directement sur le modèle de domaine.

J'ai fait de bonnes expériences avec un modèle de vue que seuls des enveloppes autour des objets de domaine et les délégués la plupart des opérations à them.This découple La vue et la couche de domaine, permet la composition flexible des objets de domaine et est toujours pas beaucoup de travail à mettre en œuvre depuis IDEs soutiennent modèle de délégation.

Answer 4

Scénarios lorsque l'objet de domaine sont problématiques à envoyer:

1. vous pouvez avoir besoin d'informations agrégées ou d'autres types de « champs calculés » envoyés à la couche d'interface utilisateur (dans l'exemple Flex / GWT) et ne veulent pas gâcher l'objet Domaine
2. vous pouvez rencontrer un besoin de sérialisation graphe cyclique d'objet (dans votre exemple, si l'étudiant avait Liste lien de parenté), certains protocoles ont des problèmes avec cette
3. Mise en veille prolongée LazyInitializationException lorsqu'ils traitent avec les serializers cadres (BlazeDS pour sérialiseur flex / GWT)

Je ne suis pas sûr que c'est une réponse claire et nette dans ces cirumcstances

Answer 5

À mon avis, il n'y a pas de problème du tout avec l'aide d'objets de modèle de domaine dans toutes les couches. Vous avez dit que vous n'avez pas besoin de toutes les informations. Lorsque vous êtes dans vos pages JSP, utilisez uniquement les données que vous avez besoin. Personne ne vous oblige à aller chercher tous les biens. Vous avez également dit que vous avez besoin de faire des calculs liés aux propriétés de l'objet afin d'obtenir GPA, nombre d'élèves, etc. Vous avez 3 options: créer des propriétés de synthèse dans votre modèle objet de domaine qui renvoient les bonnes données pour vous, enveloppé belle et soigné; effectuer les calculs soit dans la couche de contrôle ou d'un service, et de les exposer à travers les getters appropriés; ou manipuler tout l'intérieur de votre JSP. Vous devez récupérer / compiler / wrangle la FAÇON de données, alors pourquoi ajouter plus de complexité avec un DTO.

En outre, chaque DTO, vous créez un.) Une classe supplémentaire que vous avez maintenant à maintenir, et b.) Au moins 1 méthode supplémentaire quelque part dans une classe qui construit et renseigne le DTO (DAO, méthode de fabrication, etc.). Plus d'entretien = développeur malheureux 6 mois plus tard.

Alors, il y a mes arguments contre DTO. Je ne les utiliser, mais seulement dans certains scénarios, comme quand je vraiment besoin d'optimiser la vitesse et / ou l'utilisation de la mémoire, et le coût d'hydratation d'un objet de modèle complet de domaine est beaucoup trop. Les services Web sont un bon exemple quand je préfère DTO d'utilisation.

Answer 6

Le comportement d'une classe, ou ses méthodes internes ne doivent pas être exposés à des couches non concernées par leur comportement. Le transfert de données, pas de comportement. Utiliser domaine des objets dans le domaine. Le web est pas un domaine contrôlé, et les développeurs UI besoin inquiétez pas avec le comportement de domaine, seulement des données.

Le nom de domaine doit être encapsulé et protégé contre toute modification par une personne non concerné par la santé du domaine.

comportement est Leaking pas la meilleure habitude.

Si elle est un petit projet, construit avec correct aussi bien Principes. De cette façon, nous gardons toujours à l'esprit pourquoi nous faisons ce que nous faisons, et pas seulement comment.

Answer 7

Je pense que nous devrions considérer ici en premier lieu est le coût de l'introduction de nouvelles couches. Prenez DTO par exemple - faire que nous avons besoin d'une cartographie. Comme quelqu'un l'a dit, la traduction est mal et doit être évitée autant que possible.

D'autre part, je pense qu'il ya très peu de choses que vous devriez généralement pas faire. Ceux qui disent que tous les DTO sont mal sont mal - cela dépend toujours du cas d'utilisation! Sont-ils vraiment justifiés?

Et enfin, je crois personnellement les objets de domaine devraient se laisser aller à la vue elle-même. Imaginez ce que l'intégration de portillon incorporé alors comme. Mais prenez Spring MVC par exemple - domaine resterait alors dans la couche d'application probablement ...

Answer 8

DTO est largement considéré comme un anti-modèle de nos jours, et les conseils est généralement « les éviter à tout prix ».

L'un des principaux avantages d'un cadre ORM comme Hibernate, est que vous pouvez utiliser des objets de domaine à tous les niveaux, et ne DTO pas vraiment besoin. La mise en garde, bien sûr, est que vous devez consacrer quelque temps à penser à ces relations. Quand utiliser paresseux fetching, quand utiliser avide, etc