2010-10-04 9 views
42

Quelle est la différence entre un objet modèle MVC, un objet de domaine et un DTO?Quelle est la différence entre un objet modèle MVC, un objet de domaine et un DTO

Ma compréhension est:

MVC objet Modèle:

Modèles les données à afficher par une vue correspondante. En tant que tel, il peut ne pas correspondre directement à un objet de domaine, c'est-à-dire inclure des données provenant d'un ou plusieurs objets de domaine.

  1. côté client
  2. Peut contenir la logique métier, par exemple validation, propriétés calculées, etc.
  3. Aucune persistance des méthodes liées

objet Domaine:

objet que les modèles d'un objet du monde réel dans le domaine des problèmes comme la réservation, le client, ORDER, etc. Utilisé pour persiste des données .

  1. côté serveur
  2. Aucune logique commerciale

DTO (transfert de données objet):

Un objet utilisé pour transférer des données entre les couches lorsque les couches sont dans des processus distincts, par exemple d'une base de données à une application cliente. Permet une transaction unique sur le réseau plutôt que plusieurs appels. Un DTO contient seulement des méthodes de données et d'accesseurs, pas de logique. Les données sont pour une transaction particulière DB peut donc ne peuvent pas directement sur un objet de domaine, à savoir peut inclure des données provenant d'un ou plusieurs objets de domaine.

  1. occasion des deux côtés comme passé entre les couches
  2. Pas de logique métier
  3. Aucune persistance de méthodes liées

donc aux questions suivantes:

(1) Est-ce que je comprends bien? Est-ce que je manque des points clés?

(2) Y a-t-il des raisons de ne pas utiliser des objets de domaine comme le modèle MVC en supposant que les objets modèles ne nécessitent pas de logique métier supplémentaire?

(3) Y a-t-il des raisons de ne pas utiliser DTO comme le modèle MVC en supposant que les objets modèles ne nécessitent pas de logique métier supplémentaire?

Merci.

Tim

+5

bonne question .. +1 – nawfal

Répondre

7

Le Domaine et DTO peuvent également être vos objets « modèle » - vous pouvez avoir une vue de rendre les détails de l'objet de domaine « client ».

Un objet de domaine peut avoir la logique métier pour faire respecter les propriétés de l'entité de domaine. la validation en est un exemple.L'objet domaine ne contient pas de méthodes liées à la persistance, mais peut avoir des méta-données (comme des annotations) pour prendre en charge la persistance

le modèle de programmation POJO permet d'utiliser le même objet que votre domaine, vos objets DTO et vos objets de modèle - essentiellement, vous ne serez pas implémenté d'interfaces externes qui ne s'appliqueront qu'à une couche mais ne s'appliquent pas aux autres.

+1

Oui c'est ce que je fais. En effet, dans presque tous les cas, je n'ai jamais eu besoin d'utiliser autre chose que l'objet Domain. DTO serait pour une requête complexe avec plusieurs éléments de données couvrant les objets de domaine. –

+1

Et une classe de modèle MVC distincte n'est vraiment nécessaire que s'il y a une logique/traitement métier significatif associé aux données du modèle à afficher? –

+1

oui, ce sera une raison pour avoir un bon modèle dédié plutôt que d'utiliser un objet domaine. Votre objet de domaine peut stocker la date seulement UTC et c'est suffisant pour toute votre logique biz également. Mais sur l'interface utilisateur, disons que vous devrez l'afficher dans le fuseau horaire du compte de l'utilisateur. Un modèle sera utile pour effectuer ces calculs spécifiques à l'interface utilisateur. – kartheek

11

Les objets de domaine et de modèle sont essentiellement les mêmes et peuvent contenir une logique métier. En fonction de l'implémentation, les objets domaine et DTO peuvent être équivalents si vous supprimez la logique métier du modèle dans une classe de service. Souvent, une variante clé du DTO est le modèle View, qui est utilisé uniquement pour transférer des données entre le modèle de domaine et la vue, même si un modèle View peut contenir de la logique, bien qu'il s'agisse simplement de logique UI.

+0

Merci aux deux intervenants. Cela me semble plus clair maintenant. Les objets de domaine peuvent avoir une logique métier comme la validation, une logique directement liée aux données. –

+2

Un objet Modèle MVC distinct est uniquement nécessaire pour encapsuler la logique liée à l'affichage des données dans la vue. Si tel n'est pas le cas, il est plus facile d'utiliser l'objet de domaine en tant qu'objet de modèle MVC. –

1
A DTO = is an object that carries data between processes. 

Mais la partie la plus intéressante est que, il n'a aucun comportement, sauf pour le stockage et la récupération de ses propres données !!!

avec la méthodologie Sticking MVC ...

Domain = subject of your entire application. 

Model = contains the (programming languages objects : EX: C# objects) to make up the universe of your application. 

Ils peuvent obvioussly avoir un comportement et des propriétés (voir la différence avec DTO).

Souvent, une application (légère) peut avoir un modèle dans lequel votre modèle est exactement votre domaine. Un autre modèle peut être un type d'objet totalement différent qui en traite un autre. Les deux, dans ce cas, font partie de votre domaine et sont nommés "modèles de domaine - objets".

J'espère que cette réponse est exhaustive et que tout est clair pour vous!

0

1) Non, c'est une définition de ViewModel. MVC Model Object et Domain Object sont identiques.
2) Les modèles de domaine (objets) sont toujours présents, la logique métier est facultative
3) S'il n'y a pas de logique métier dans l'objet Domaine, il devient automatiquement DTO.

0

Toute définition pour la plupart des objets est différents selon le lieu d'utilisation d'objets:

Model: est une définition générale pour l'utilisation objet dans client ou serveur.

  1. Model View: est un objet en utilisant dans client la plupart du temps.
  2. Domain Object: est un objet utilisant server et transfering data to the database.
  3. Data Transfer Object(DTO): est un objet qui les données de transfert d'un objet à un autre objet, spécialement pour obtenir des données en API Call (par exemple: en api méthode GET appel pour obtenir les données que vous ne devez pas donner des modèles de base de données client, à cet effet, vous utilisez dto).

Remarque: the definitions are true most of the time mais dans certaines situations, ce n'est pas pratique.

Questions connexes