Plain Old CLR objet vs transfert de données objet

Question

POCO = Plain Old CLR (ou mieux: Classe) Objet

DTO = transfert de données objet

Dans ce post il y a une différence, mais franchement la plupart des blogs que je lis décrire POCO de la manière DTO est définie. DTO sont des conteneurs de données simples utilisées pour déplacer des données entre les couches d'une application

sont POCO et DTO la même chose?

Answer 1

A POCO suit les règles de la POO. Il devrait (mais ne pas avoir) état et comportement. POCO vient de POJO, inventé par Martin Fowler [ anecdote ]. Il a utilisé le terme POJO comme un moyen de rendre plus sexy de rejeter le cadre des implémentations EJB lourds. POCO doit être utilisé dans le même contexte dans .Net. Ne laissez pas les cadres dictent la conception de votre objet.

Un seul but de DTO est de transférer l'état, et ne devrait avoir aucun comportement. Voir Martin Fowler d'un DTO pour un exemple de l'utilisation de ce schéma.

Voilà la différence: POCO décrit une approche à la programmation (bon vieux objet façonné la programmation orientée), où DTO est un modèle qui est utilisé pour « données de transfert » à l'aide les objets.

Alors que vous pouvez traiter Poços comme DTO, vous courez le risque de créer un si vous le faites. De plus, il y a une disparité dans la structure, puisque DTO devraient être conçus pour transférer des données, ne pas représenter la vraie structure du domaine des affaires. Le résultat est que DTO ont tendance à être plus plat que votre domaine actuel.

Dans un domaine de toute la complexité raisonnable, vous êtes presque toujours mieux de créer domaine séparé Poços et les traduire en DTO. DDD (conception conduit de domaine) définit le couche anti-corruption (un autre lien ici , mais la meilleure chose à faire est acheter livre), ce qui est une bonne structure qui rend la séparation claire.

Answer 2

Il est probablement inutile pour moi de contribuer depuis je l'ai déjà dit ma position dans mon article de blog, mais le dernier paragraphe de ce genre d'article des sommes choses:

Donc, en conclusion, apprendre à aimer Poco, et assurez-vous de ne pas propager toute information erronée à ce sujet étant la même chose que d'un DTO. DTO sont des conteneurs de données simples utilisées pour déplacer des données entre les couches d'une application. Poços sont des objets d'affaires à part entière avec une exigence qu'ils sont persistance Ignorants (pas get ou sauvegardent méthodes). Enfin, si vous ne l'avez pas encore vérifié le livre de Jimmy Nilsson, ramasser de vos piles universitaires locales. Il a des exemples en C # et il est une excellente lecture.

BTW, Patrick Je lis Poco comme un article de mode de vie, et je suis entièrement d'accord, c'est un article fantastique. Il est en fait une section du livre Jimmy Nilsson que je recommande. Je ne savais pas qu'il était disponible en ligne. Son livre est vraiment la meilleure source d'information que j'ai trouvé Poco / DTO / repository / et d'autres pratiques de développement DDD.

Answer 3

POCO est tout simplement un objet qui ne prend pas une dépendance à l'égard d'un cadre extérieur. Il est PLAIN.

Si un POCO a un comportement ou non est sans importance.

A DTO peut être POCO de même qu'un objet de domaine (ce qui serait typiquement riche en comportement).

Typiquement DTO sont plus susceptibles de prendre des dépendances sur les cadres externes (par exemple les attributs.) À des fins de sérialisation que généralement ils sortent à la limite d'un système.

Dans les architectures typiques de style oignon (souvent utilisé dans une large approche DDD), la couche de domaine est placé au centre et si ses objets ne doit pas, à ce stade, ont des dépendances à l'extérieur de cette couche.

Answer 4

J'ai écrit un article pour ce sujet: DTO vs vs valeur objet POCO .

En bref:

• DTO! = Valeur objet
• DTO ⊂ POCO
• Valeur objet POCO ⊂

Answer 5

Je pense que DTO peut être un POCO. DTO est plus sur l'utilisation de l'objet en POCO est plus du style de l'objet (découplée de concepts architecturaux).

Un exemple où un POCO est quelque chose de différent que DTO est quand vous parlez de POCO dans votre modèle logique modèle de domaine / entreprise, ce qui est une belle représentation OO de votre domaine de problème. Vous pouvez utiliser toute l'application de Poco, mais cela pourrait avoir un effet secondaire indésirable une telle fuite de connaissances. de DTO sont par exemple utilisés à partir de la couche de service qui communique avec l'interface utilisateur, sont une représentation plane de la DTO des données, et sont utilisés uniquement pour fournir l'interface utilisateur avec des données, et des modifications des communications de retour à la couche de service. La couche de service est en charge de la cartographie dans les deux sens de la DTO aux objets de domaine POCO.

Mise à jour dit que cette approche est une route lourde à prendre, et ne doit être prise s'il y a un décalage important entre la couche de domaine et l'interface utilisateur.

Answer 6

Un cas d'exploitation principale pour un DTO est dans les données de retour d'un service Web. Dans ce cas, POCO et DTO sont équivalentes. Tout comportement dans le POCO serait retiré quand il est retourné d'un service Web, il ne compte pas vraiment si oui ou non il a un comportement.

Answer 7

ici est la règle générale: DTO == mal et indicateur de logiciels sur-ingénierie. == POCO bien. « modèles d'entreprise » ont détruit le cerveau d'un grand nombre de personnes dans le monde Java EE. S'il vous plaît ne pas répéter l'erreur dans la terre .NET.

Answer 8

les classes DTO sont utilisées pour la sérialisation / délinéariser les données provenant de différentes sources. Lorsque vous voulez désérialiser un objet à partir d'une source, peu importe quelle source externe, il est: le service, le fichier, base de données, etc. vous pouvez souhaitez utiliser uniquement une partie de cela, mais vous voulez un moyen facile de désérialiser que les données à un objet. après que vous copiez ces données au XModel que vous souhaitez utiliser. Un sérialiseur est une belle technologie pour charger des objets DTO. Pourquoi? vous avez seulement besoin d'une fonction de chargement (deserialize) l'objet.

Answer 9

TL; DR:

A DTO décrit le motif de transfert d'état. Un POCO ne décrit rien. Il est une autre façon de dire « objet » en POO. Il vient de POJO (Java), inventé par Martin Fowler qui littéralement décrit comme un nom pour colombophile « objet », car « objet » est pas très sexy.

A DTO est un modèle d'objet utilisé pour transférer l'état entre les couches de préoccupation. Ils peuvent avoir un comportement (à savoir peut 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.

A POCO est un objet simple, mais ce que l'on entend par « plaine » est que ce n'est pas spécial. Cela signifie simplement qu'il est un objet CLR sans motif implicite à elle. Un terme générique. Il ne se fait pas de travailler avec un autre cadre. Donc, si votre POCO a [JsonProperty] ou décorations EF partout 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:

• Voir le modèle : utilisé pour modéliser des données pour une vue. Habituellement, contient des annotations de données pour aider la liaison et la validation. En MVVM, il agit également comme un contrôleur. Il est plus d'un DTO
• Valeur objet : utilisé pour représenter les valeurs
• Racine Aggregate : utilisé pour gérer l'état et invariants
• Handlers : pour répondre à un événement / message
• Attributs : utilisé comme décoration pour faire face 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
• L'usine : permet de configurer et / ou assembler des objets complexes à utiliser lorsque le constructeur est pas assez bon. Également utilisé pour prendre des décisions sur les objets doivent être créés lors de l'exécution.
• Dépôt / DAO : utilisé pour les données d'accès

Ce sont tous les objets juste, mais il faut noter que la plupart d'entre eux sont généralement liés à un modèle. Ainsi, vous pouvez les appeler des « objets » ou vous pourriez être plus précis au sujet de son intention et l'appeler par ce qu'il est. Ceci est également la raison pour laquelle nous avons des modèles de conception; pour décrire des concepts complexes dans quelques œuvres. DTO est un motif. racine globale est un modèle, vue modèle est un modèle (par exemple MVC & MVVM). POCO n'est pas un motif.

A POCO ne décrit pas un modèle. Il est juste une façon différente de faire référence aux classes / objets POO. Pensez-y comme un concept abstrait; ils peuvent se référer à quoi que ce soit. OMI, il y a une relation à sens unique mais parce qu'une fois un objet atteint le point où il ne peut servir un but proprement, il n'y a plus de POCO. Par exemple, une fois que vous marquez votre classe avec des décorations pour le faire fonctionner avec un certain cadre, il n'y a plus de POCO. Par conséquent:

• Un DTO est un POCO
• Un Poco pas DTO
• Une vue modèle est un POCO
• Un Poco pas un modèle Voir

Le point de faire une distinction entre les deux est de garder des motifs clairs et cohérents dans l'effort de ne pas franchir les préoccupations et conduire à un couplage étroit. Par exemple, si vous avez un objet métier qui a des méthodes pour muter l'état, mais il est aussi décoré en enfer avec des décorations EF pour sauver à SQL Server et JsonProperty afin qu'il puisse être renvoyé sur un point de terminaison API. Cet objet ne toléreraient pas 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 de ne pas être enregistrées dans la base de données et d'autres marquées à ne pas être sérialisé à JSON au point final de l'API).

Donc, si vous deviez me dire quelque chose était un DTO, alors je serais probablement assurerai il n'a jamais été utilisé pour autre chose que le déplacement autour de l'état. Si vous me disiez quelque chose était un modèle de vue, je serais probablement assurerai il n'a pas été enregistré dans une se base de données. Si vous me disiez quelque chose était un modèle de domaine, alors je serais probablement assurerai il had aucune dépendance sur quoi que ce soit en dehors du domaine. Mais si vous me disiez quelque chose était un POCO, vous me dites pas vraiment grand-chose.

Answer 10

Ne même pas les appeler DTO. Ils sont appelés Modèles .... période. Les modèles ont jamais comportement. Je ne sais pas qui est venu avec cette stupide DTO terme, mais il doit être une chose .NET est tout ce que je peux comprendre. Pensez modèles de vue dans MVC, même barrage ** chose, les modèles sont utilisés pour transférer l'état entre le côté serveur couches ou pendant la période de fil, ils sont tous les modèles. Propriétés des données. Ce sont des modèles que vous passez Ove le fil. Modèles, Modèles de modèles. C'est ça.

Je souhaite que le terme stupide DTO partirait de notre vocabulaire.