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

Question

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

Voici ce que j'ai compris :

Objet modèle MVC :

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

1. Côté client
2. Peut contenir une logique commerciale. Par exemple, des validations, des propriétés calculées, etc.
3. Pas de méthodes liées à la persistance

Objet du domaine :

Un objet qui modélise un objet du monde réel dans le domaine du problème, comme une réservation, un client, une commande, etc. Utilisé pour conserver les données.

1. Côté serveur
2. Pas de logique d'entreprise

DTO (Data Transfer Object) :

Objet utilisé pour transférer des données entre les couches lorsque celles-ci se trouvent dans des processus distincts, par exemple d'une base de données à une application client. Il permet d'effectuer une seule transaction sur le câble plutôt que plusieurs appels lors de l'obtention de données correspondant à plusieurs objets de domaine. Un DTO ne contient que des données et des méthodes d'accès, sans aucune logique. Les données concernent une transaction particulière de la base de données et peuvent donc correspondre directement ou non à un objet de domaine, car elles peuvent inclure des données provenant d'un ou de plusieurs objets de domaine.

1. Utilisé à la fois du côté du serveur et du côté du client, car il est transmis entre les couches.
2. Pas de logique d'entreprise
3. Pas de méthodes liées à la persistance

Voici donc les questions qui se posent :

1. La compréhension ci-dessus est-elle correcte ? Ai-je oublié des points essentiels ?

2. Existe-t-il des raisons de ne pas utiliser les objets du domaine comme modèle MVC, en supposant que les objets du modèle ne requièrent pas de logique commerciale supplémentaire ?

3. Existe-t-il des raisons de ne pas utiliser les DTO comme modèle MVC, en supposant que les objets du modèle ne nécessitent pas de logique métier supplémentaire ?

Answer 1

Les objets du domaine et du modèle sont essentiellement les mêmes et peuvent contenir une logique commerciale. En fonction de l'implémentation, les objets de domaine et DTO peuvent être équivalents si vous retirez la logique métier du modèle pour la placer dans une classe de service.

Souvent, une variante clé du DTO est le modèle de vue, qui est utilisé uniquement pour transférer des données entre le modèle de domaine et la vue, bien qu'un modèle de vue puisse souvent contenir de la logique, même s'il ne s'agit que de logique d'interface utilisateur.

Answer 2

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

Un objet de domaine peut être doté d'une logique d'entreprise permettant d'appliquer les propriétés de l'entité du domaine. La validation est l'un de ces cas. L'objet de domaine en lui-même ne contient pas de méthodes liées à la persistance, mais il peut contenir des méta-données (comme des annotations) pour soutenir la persistance.

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

Answer 3

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

Mais le plus intéressant, c'est qu'il n'a aucun comportement à part le stockage et la récupération de ses propres données !!!

S'en tenir à la méthodologie 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 évidemment avoir un comportement et des propriétés (voir la différence avec les DTO).

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

J'espère que cette réponse est exhaustive et qu'elle est claire pour vous !

Answer 4

Ma compréhension (en bref) est la suivante :

(MVC) Objet modèle :

• représenter certaines choses dans un certain contexte d'utilisation, par exemple. PersonEditModel , PersonViewModel ou simplement PersonModel
• n'a pas de logique commerciale
• peut faire l'objet d'une logique d'évaluation, etc.
• utilisé pour fournir des données d'une couche d'application à une autre, par exemple MVC Controller <-> MVC View

Objet du domaine :

• représente un objet commercial (objet du monde réel dans le domaine du problème)
• a une logique d'entreprise
• n'autorise pas un état invalide de l'objet, dispose de méthodes permettant de modifier correctement l'état de l'objet
• utilisé pour encapsuler la logique d'entreprise qui lui est liée
• ne doivent pas être utilisés pour conserver les données (ou même ne devraient pas l'être)

DTO (Data Transfer Object) :

• similaire à l'objet Modèle mais avec une structure plate
• uniquement les propriétés/champs de type simple (chaînes, nombres, dates, booléens)
• utilisé pour transférer des données au-delà des limites de l'application, par exemple entre le serveur web et le navigateur web

Answer 5

La définition de la plupart des objets varie en fonction de leur lieu d'utilisation :

Model : est un général définition de l'utilisation objet en client o serveur .

1. Model View : est un objet en utilisant client la plupart du temps.
2. Domain Object : est un objet en utilisant server et transfering data to the database .
3. Data Transfer Object(DTO) : est un objet qui transférer des données d'un objet à un autre , notamment en ce qui concerne l'obtention de données dans les API Call (par exemple : dans l'api Méthode GET pour obtenir des données, vous ne devez pas fournir de modèles de base de données au client. dto ).

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