Objet CLR ordinaire et objet de transfert de données

Question

POCO = Plain Old CLR (ou mieux : Class) Object (objet)

DTO = Data Transfer Object (objet de transfert de données)

Dans ce poste Il y a une différence, mais franchement, la plupart des blogs que je lis décrivent POCO de la manière dont DTO est défini : Les DTO sont de simples conteneurs de données utilisés pour déplacer des données entre les couches d'une application.

Le POCO et le DTO sont-ils la même chose ?

Answer 1

TL;DR :

Un DTO décrit le modèle de transfert d'état. Un POCO ne décrit rien du tout. C'est une autre façon de dire "objet" dans la POO. Il vient de POJO (Java), inventé par Martin Fowler qui le décrit littéralement comme un nom plus sophistiqué pour "objet" parce que "objet" n'est pas très sexy.

Un DTO est un modèle d'objet utilisé pour transférer l'état entre les couches de préoccupation. Ils peuvent avoir un comportement (c'est-à-dire qu'ils peuvent techniquement être un poco) tant que ce comportement ne modifie pas l'état. Par exemple, il peut avoir une méthode qui se sérialise.

Un POCO est un objet ordinaire, mais ce que l'on entend par "ordinaire", c'est qu'il n'est pas spécial. Cela signifie simplement qu'il s'agit d'un objet CLR sans motif implicite. Un terme générique. Il n'est pas conçu pour fonctionner avec un autre cadre. Donc si votre POCO a [JsonProperty] ou des décorations EF partout sur ses propriétés, par exemple, alors je dirais que ce n'est pas une POCO.

Voici quelques exemples de différents types de modèles d'objets à comparer :

• Voir le modèle Utilisé pour modéliser les données d'une vue. Il comporte généralement des annotations de données pour faciliter la liaison et la validation. Dans MVVM, il fait également office de contrôleur. C'est plus qu'un DTO
• Objet de valeur : utilisé pour représenter des valeurs
• Racine de l'agrégat : utilisé pour gérer l'état et les invariants
• Manipulateurs : utilisé pour répondre à un événement/message
• Attributs : utilisé comme décorations pour traiter des préoccupations transversales
• Service : utilisé pour effectuer des tâches complexes
• Contrôleur : utilisé pour contrôler le flux des demandes et des réponses
• Usine Utilisé pour configurer et/ou assembler des objets complexes à utiliser lorsqu'un constructeur n'est pas suffisant. Également utilisé pour prendre des décisions sur les objets qui doivent être créés au moment de l'exécution.
• Référentiel/DAO : utilisé pour accéder aux données

Ce ne sont que des objets, mais remarquez que la plupart d'entre eux sont généralement liés à un motif. Vous pouvez donc les appeler "objets" ou être plus spécifique quant à leur intention et les appeler par ce qu'ils sont. C'est aussi la raison pour laquelle nous avons des patrons de conception ; pour décrire des concepts complexes en quelques ouvrages. DTO est un modèle. Aggregate Root est un modèle, View Model est un modèle (par exemple MVC & MVVM). POCO n'est pas un modèle.

Un POCO ne décrit pas un modèle. C'est juste une façon différente de se référer aux classes/objets dans la POO. Considérez-le comme un concept abstrait ; il peut faire référence à n'importe quoi. IMO, il s'agit d'une relation à sens unique, car lorsqu'un objet atteint le point où il ne peut servir qu'un seul objectif proprement, il n'est plus un POCO. Par exemple, une fois que vous avez marqué votre classe avec des décorations pour la faire fonctionner avec un cadre quelconque, ce n'est plus un POCO. Par conséquent :

• Un DTO est un POCO
• Un POCO n'est pas un DTO
• Un modèle de vue est un POCO
• Un POCO n'est pas un modèle de vue

L'intérêt de faire une distinction entre les deux est de garder les modèles clairs et cohérents afin de ne pas croiser les préoccupations et conduire à un couplage étroit. Par exemple, si vous avez un objet métier qui possède des méthodes pour modifier l'état, mais qui est également décoré à l'infini avec des décorations EF pour la sauvegarde sur le serveur SQL et JsonProperty afin qu'il puisse être renvoyé sur un endpoint API. Cet objet serait intolérant au changement, et serait probablement jonché de variantes de propriétés (par exemple UserId, UserPk, UserKey, UserGuid, où certaines d'entre elles sont marquées pour ne pas être sauvegardées dans la base de données et d'autres pour ne pas être sérialisées en JSON au point de terminaison de l'API).

Ainsi, si vous me disiez que quelque chose est un DTO, je m'assurerais probablement qu'il n'est jamais utilisé pour autre chose que le déplacement d'un état. Si vous me disiez que quelque chose était un modèle de vue, je m'assurerais probablement qu'il n'est pas enregistré dans une base de données. Si vous me disiez que quelque chose était un modèle de domaine, je m'assurerais probablement qu'il ne dépend pas de quelque chose en dehors du domaine. Mais si vous me disiez que quelque chose était un POCO, vous ne me diriez pas grand-chose.

Answer 2

L'un des principaux cas d'utilisation d'un DTO est le retour de données depuis un service web. Dans ce cas, le POCO et le DTO sont équivalents. Tout comportement dans le POCO sera supprimé lorsqu'il sera renvoyé par un service web, donc il n'est pas vraiment important qu'il ait un comportement ou non.

Answer 3

Les classes DTO sont utilisées pour sérialiser/désérialiser des données provenant de différentes sources. Lorsque vous souhaitez désérialiser un objet à partir d'une source, peu importe la source externe : service, fichier, base de données, etc., il se peut que vous ne souhaitiez en utiliser qu'une partie, mais vous voulez un moyen facile de désérialiser ces données en un objet. Après cela, vous copiez ces données dans le modèle X que vous souhaitez utiliser. Un sérialiseur est une technologie idéale pour charger des objets DTO. Pourquoi ? Vous n'avez besoin que d'une seule fonction pour charger (désérialiser) l'objet.

Answer 4

Voici la règle générale : DTO==mauvais et indicateur de logiciel sur-ingénierie. POCO==bien. Les modèles d'entreprise ont détruit le cerveau de beaucoup de personnes dans le monde Java EE. S'il vous plaît, ne répétez pas cette erreur au pays de .NET.

Answer 5

Ne les appelez même pas DTOs. Ils s'appellent Modèles ....Period. Les modèles n'ont jamais de comportement. Je ne sais pas qui a inventé ce terme stupide de DTO mais ce doit être un truc de .NET, c'est tout ce que je peux imaginer. Pensez aux modèles de vue dans MVC, c'est la même chose, les modèles sont utilisés pour transférer l'état entre les couches côté serveur ou sur le fil, ce sont tous des modèles. Des propriétés avec des données. Ce sont des modèles que vous passez sur le fil. Modèles, modèles, modèles. C'est tout.

J'aimerais que le terme stupide DTO disparaisse de notre vocabulaire.