préfixant DTO / POCOS - Conventions de nommage?

Question

question simple, vraiment, je voulais savoir ce que les conventions de nommage quiconque met là-bas DTO / POCOS ....

Je ne veux pas vraiment comme préfixe la notation hongroise .. Je suis loin de ça!.

Mais mes dtos de noms se heurtent aux noms de mes objets réels retournés et bien qu'ils soient dans un autre espace de nommage son encore un peu confus ..

Je me demandais ce que tout le monde nommage conventions s'y applique

par exemple mon objet client est appelé client

et je fais une mise en correspondance de DTO ... qui est client .. iwas penser DtoCustomer ..

Je ne sais pas

Tout le monde?

Answer 1

Je préfère utiliser les espaces de noms pour cela. Utilisation d'alias d'espace de noms pour ce qui rend encore plus clair.

Cela ferait du code qui ressemble à:

Customer myCustomer = new Customer();
Dto.Customer dtoCustomer = ....;

Si je travaille entièrement dans la couche DTO, je peux encore travailler avec « Client » à ce stade.

Answer 2

Dans mon expérience, ce sont souvent des sous-ensembles DTO ou agrégations de données que vos entités de domaine représentent. Ceci est généralement parce que les entités de domaine sont riches, complexes, des objets très liés entre eux qui ont à la fois le comportement et les données. En tant que tel, j'essaie de nommer mon DTO pour refléter autant que possible le sous-ensemble de l'information qu'ils représentent. Dans le cas des clients, j'ai souvent DTO que parfaitement adaptés aux besoins de l'information demandée:

• CustomerHeader
• CustomerDetail
• CustomerWithRecentOrders
• CustomerAndBill

Dans les exemples ci-dessus, CustomerHeader ne contiendrait probablement le numéro de client et le nom, souvent utilisé pour afficher les clients dans les listes simples. CustomerDetail contiendrait la plupart des informations des clients, mais ne contiendrait aucune des propriétés relationnelles qu'une entité client épanouie est susceptible de contenir. Les autres doivent être explicites, ce qui est le but ultime.

Answer 3

J'aime CustomerDto plus DtoCustomer. Comme pour les avoir classés à côté de l'autre.

Mais la dénomination peut aussi dépendre de l'utilisation de la DTO. Par exemple, dans un ASP.NET MVC que j'appelle souvent un DTO qui est envoyé à une vue pour CustomerViewModel.

Answer 4

Je joins généralement DTO dans des situations comme celle-ci.