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 ?
Un POCO suit les règles de la POO. Il devrait (mais n'est pas obligé) avoir un état et comportement. POCO vient de POJO, inventé par Martin Fowler [ anecdote ici ]. Il a utilisé le terme POJO comme un moyen de rendre plus sexy le rejet des implémentations EJB lourdes. POCO devrait être utilisé dans le même contexte dans .Net. Ne laissez pas les frameworks dicter la conception de vos objets.
Le seul but d'un DTO est de transférer un état, et il ne doit pas avoir de comportement. Voir l'article de Martin Fowler explication d'un DTO pour un exemple d'utilisation de ce modèle.
Voilà la différence : Le POCO décrit une approche de la programmation (la bonne vieille programmation orientée objet), où DTO est un modèle qui est utilisé pour "transférer des données" à l'aide d'objets.
Bien que vous puissiez traiter les POCOs comme des DTOs, vous courez le risque de créer une modèle de domaine anémique si vous le faites. En outre, il y a un décalage dans la structure, puisque les DTO doivent être conçus pour transférer des données, et non pour représenter la véritable structure du domaine d'activité. Il en résulte que les DTO ont tendance à être plus plats que votre domaine réel.
Dans un domaine d'une complexité raisonnable, il est presque toujours préférable de créer des POCO de domaine séparés et de les traduire en DTO. Le DDD (domain driven design) définit les couche anti-corruption (autre lien aquí mais la meilleure chose à faire est acheter le livre ), qui est une bonne structure qui rend la ségrégation claire.
Je sais que j'ai souvent fait référence à Martin Fowler ici, mais c'est lui qui a inventé le terme POJO, et qui a écrit le livre PoEAA qui est la référence définitive pour les DTO.
Je ne suis pas sûr qu'un DTO ne doive pas avoir de comportements, à en juger par le diagramme de Martin Fowler, les DTO pourraient avoir des comportements.
@Beatles1692, les méthodes représentées sont du code de sérialisation. C'est probablement une déclaration trop large pour dire "pas de comportement". Que diriez-vous de "aucune logique commerciale". Le code de sérialisation, et les objets de bas niveau comme le code de hachage, l'égalité et le tostring devraient être acceptables.
Il est probablement redondant pour moi de contribuer puisque j'ai déjà exposé ma position dans mon article de blog, mais le dernier paragraphe de cet article résume bien les choses :
En conclusion, apprenez à aimer la POCO et veillez à ne pas répandre de fausses informations selon lesquelles elle serait la même chose qu'un DTO. Les DTO sont de simples conteneurs de données utilisés pour déplacer les données entre les couches d'une application. Les POCO sont des objets métier à part entière, à la seule condition qu'ils ne tiennent pas compte de la persistance (pas de méthodes d'obtention ou de sauvegarde). Enfin, si vous n'avez pas encore lu le livre de Jimmy Nilsson, allez le chercher dans les rayons de votre université. Il contient des exemples en C# et c'est une excellente lecture.
BTW, Patrick, j'ai lu l'article sur le POCO en tant que style de vie, et je suis tout à fait d'accord, c'est un article fantastique. C'est en fait une section du livre de Jimmy Nilsson que je vous ai recommandé. Je ne savais pas qu'il était disponible en ligne. Son livre est vraiment la meilleure source d'information que j'ai trouvée sur les POCO / DTO / Repository / et autres pratiques de développement DDD.
POCO est simplement un objet qui ne prend pas de dépendance sur un cadre externe. Il est PLAIN.
Qu'un POCO ait un comportement ou non est sans importance.
Un DTO peut être POCO tout comme un objet de domaine (qui serait typiquement riche en comportement).
En général, les DTO sont plus susceptibles de prendre des dépendances sur des cadres externes (par exemple, des attributs) à des fins de sérialisation, car ils sortent généralement à la limite d'un système.
Dans les architectures typiques de style oignon (souvent utilisées dans le cadre d'une approche DDD au sens large), la couche de domaine est placée au centre et ses objets ne devraient donc pas, à ce stade, avoir de dépendances en dehors de cette couche.
J'ai écrit un article à ce sujet : DTO vs Value Object vs POCO .
En bref :
Je pense qu'un DTO peut être un POCO. Le DTO concerne davantage l'utilisation de l'objet tandis que le POCO concerne davantage le style de l'objet (découplé des concepts architecturaux).
Un exemple où un POCO est différent d'un DTO est lorsque vous parlez de POCO à l'intérieur de votre modèle de domaine/modèle logique d'entreprise, qui est une belle représentation OO de votre domaine de problèmes. Vous pourriez utiliser les POCO dans toute l'application, mais cela pourrait avoir des effets secondaires indésirables, comme des fuites de connaissances. Les DTO sont par exemple utilisés par la couche de service avec laquelle l'interface utilisateur communique. Les DTO sont des représentations plates des données et ne servent qu'à fournir des données à l'interface utilisateur et à communiquer les modifications à la couche de service. La couche service est chargée de mettre en correspondance les DTO dans les deux sens avec les objets du domaine POCO.
Mise à jour Martin Fowler a déclaré que cette approche est une voie lourde à emprunter, et qu'elle ne devrait être adoptée que s'il existe un décalage important entre la couche de domaine et l'interface utilisateur.
David Landman, le lien que vous avez inclus concerne le modèle DTO local, c'est-à-dire lorsque les DTO sont utilisés pour transférer l'état à l'intérieur des limites de votre système. Dans ces cas, vous devez être très prudent, car au sein de votre système, vous devriez déjà avoir un domaine bien défini qui peut être partagé. Lors du transfert d'état au-delà des frontières du système, le DTO est difficile à éviter et plutôt approprié dans tous les cas.
@Michal Meadows, oui, le lien parle effectivement d'un sous-ensemble différent de problèmes. Mais je pense que dans le cas du transfert d'état à travers une frontière de système, vous devriez utiliser un service de traduction pour mettre en correspondance le POCO d'un contexte avec le POCO de l'autre contexte. Ou bien parlez-vous de frontières au niveau du système ?
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
5 votes
"POCO = Plain Old CLR (ou mieux : Class) Object". Ainsi, les objets de cette nature dans VB.NET seraient également des POCO, et non des POVO.