prefixing DTO / POCOS - naming conventions?

Question

Hi there,

simple question really, i was wanting to know what naming conventions anybody puts on there DTO / POCOS ....

I didn't really want to prefix like hungarian notation.. i got away from that!.

But my dtos naming are clashing with my actual returned object names and although they are in a different namespace its still a bit confusing..

I was wondering what naming conventions anybody applies to it

for example my customer object is called Customer

and i do a mapping to dto ... which is Customer.. iwas thinking DtoCustomer ..

Not sure

Anyone ?

Answer 1

I like CustomerDto more than DtoCustomer. Like to have them sorted next to each other.

But the naming can also depend on the usage of the DTO. For example in an ASP.NET MVC I often call a DTO that is sent to a view for CustomerViewModel.

Answer 2

I prefer to use namespaces for this. Using namespace aliases for this makes it even more clear.

This would make code that looks like:

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

If I'm working entirely in the DTO layer, I still can work with "Customer" at this point.

Answer 3

I typically append DTO in situations like this.

Answer 4

In my experience, DTO's are often subsets or aggregations of data that your domain entities represent. This is usually because domain entities are rich, highly inter-related, complex objects that have both behavior and data. As such, I try to name my DTO's to reflect as much as possible the subset of information they represent. In the case of customers, I often have DTO's that are fine-tuned to the information being requested:

• CustomerHeader
• CustomerDetail
• CustomerWithRecentOrders
• CustomerAndBill

In the examples above, CustomerHeader would likely only contain the customer ID and Name, often used to display customers in simple lists. CustomerDetail would contain most customer information, but wouldn't contain any of the relational properties that a full blown Customer entity is likely to contain. The others should be self explanatory, which is the ultimate goal.