TL; DR:
Un DTO décrit le modèle de transfert d'état. Un POCO ne décrit rien. 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 concernées. Ils peuvent avoir un comportement (c'est-à-dire peuvent techniquement être un poco) tant que ce comportement ne mute pas l'état. Par exemple, il peut avoir une méthode qui se sérialise.
Un POCO est un objet simple, mais ce que l'on entend par «simple», c'est qu'il n'est pas spécial. Cela signifie simplement que c'est un objet CLR sans motif implicite. Un terme générique. Il n'est pas fait pour fonctionner avec un autre cadre. Donc, si votre POCO a des [JsonProperty]décorations EF ou partout dans ses propriétés, par exemple, alors je dirais que ce n'est pas un POCO.
Voici quelques exemples de différents types de modèles d'objets à comparer:
- Afficher le modèle : utilisé pour modéliser les données d'une vue. A généralement des annotations de données pour faciliter la liaison et la validation. Dans MVVM, il agit également comme un contrôleur. C'est plus qu'un DTO
- Objet de valeur : utilisé pour représenter des valeurs
- Racine agrégée : utilisée pour gérer l'état et les invariants
- Gestionnaires : utilisés pour répondre à un événement / message
- Attributs : utilisés comme décorations pour répondre aux 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 assez bon. Également utilisé pour prendre des décisions sur les objets à créer lors de l'exécution.
- Référentiel / DAO : utilisé pour accéder aux données
Ce ne sont que des objets, mais notez que la plupart d'entre eux sont généralement liés à un motif. Vous pouvez donc les appeler «objets» ou vous pouvez être plus précis sur son intention et l'appeler par ce qu'elle est. C'est aussi pourquoi nous avons des modèles de conception; décrire des concepts complexes dans quelques ouvrages. Le DTO est un modèle. La racine agrégée est un modèle, View Model est un modèle (par exemple MVC et MVVM). POCO n'est pas un modèle.
Un POCO ne décrit pas un modèle. C'est juste une manière différente de se référer aux classes / objets dans la POO. Considérez-le comme un concept abstrait; ils peuvent faire référence à n'importe quoi. OMI, il y a une relation à sens unique, car une fois qu'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 marquez votre classe avec des décorations pour la faire fonctionner avec un cadre, ce n'est plus un POCO. Donc:
- 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
Le but de faire une distinction entre les deux est de maintenir des schémas clairs et cohérents afin de ne pas croiser les préoccupations et conduire à un couplage serré. Par exemple, si vous avez un objet métier qui a des méthodes pour muter l'état, mais qui est également décoré en enfer avec des décorations EF pour l'enregistrement dans SQL Server ET JsonProperty afin qu'il puisse être renvoyé via un point de terminaison API. Cet objet serait intolérant à changer, et serait probablement jonché de variantes de propriétés (par exemple UserId, UserPk, UserKey, UserGuid, où certains d'entre eux sont marqués pour ne pas être enregistrés dans la base de données et d'autres marqués pour ne pas être sérialisés vers JSON au point de terminaison API).
Donc, si vous me disiez que quelque chose était un DTO, je m'assurerais probablement qu'il n'a jamais été utilisé pour autre chose que pour déplacer l'état. Si vous me disiez que quelque chose était un modèle de vue, je m'assurerais probablement qu'il ne soit pas enregistré dans une base de données. Si vous m'avez dit que quelque chose était un modèle de domaine, je m'assurerais probablement qu'il ne dépendait de rien en dehors du domaine. Mais si vous me disiez que quelque chose était un POCO, vous ne me diriez pas grand-chose du tout.