la différence entre un DTO et un POCO

• Data Transfer Object (DTO):

Un DTO stocke des données. Il n'a pas de méthode (comportement) autre que les accesseurs et mutateurs qui ne sont utilisés que pour lire et modifier les données.

C'est juste un simple conteneur de données léger, utilisé pour déplacer les données entre les couches.

• Plain Old CLR Objet, ou Plain Old C# Object:

Un POCO n'est pas un DTO ,c'est essentiellement la version .Net d'un POJO, Plain Old Java Object. Un POCO est votre objet métier. Il dispose de données, de logique de validation et de toute autre logique métier que vous voulez y mettre.Le terme que vous entendrez pour ce concept est « Persistance Ignorance » (PI). Les POCO ignorent la logique de persistance.

Les POCO doivent être alimentés par une autre classe qui encapsule la logique de persistance de cette entité, comme un Repository ou un Contrôleur de Données. En général, j'utilise un Repository.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Je préfère une architecture POCO/Repository/DTO, mais ce n'est pas la seule bonne façon de concevoir une application.

Je pense que les avantages sont que c'est une architecture très propre et très facile à maintenir. Elle assure la séparation de la logique métier et de la logique de persistance,

qui est plus conforme au Principe de Responsabilité Unique (Single Responsibility Principle).

Utiliser des POCO avec des DTO et une DAL bien conçue est à peu près la meilleure architecture que vous puissiez construire. Mais, je pense que la plupart des développeurs .NET seront

amenés à utiliser des POCO et des Repositories (mais pas de DTO) via les ORM (NDT : mapping objet-relationnel). Entity Framework, NHibernate, et beaucoup de ces ORM exigent

ou partent du principe que l'architecture est de type POCO.

En fait, Entity Framework a introduit une interface IPOCO dont j'ai du mal à trouver de la documentation, mais cela ressemble à quelque chose de bien.

D'autre part, si vous voulez vous mettre au Domain Driven Design, vous devrez adopter les POCO.

Conclusion

Donc, en conclusion, les DTO sont de simples conteneurs de données, utilisés pour transférer des données entre les couches d'une application.

Les POCO sont des objets métier à part entière avec la caractéristique qu'ils ignorent la logique de persistance (aucune méthode get() ni save() ).