23

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 ?

BengtBe
  • 4,465
  • 1
  • 26
  • 19
mark smith
  • 20,637
  • 47
  • 135
  • 187

4 Answers4

24

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.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • Yes i adopted this in the end, i have my models in the namespace models and my dtos in dto.. thanks – mark smith Nov 09 '09 at 10:29
  • That had never occured to me. Awesome. I love it. I want some more of it. – Sinaesthetic Aug 31 '12 at 17:09
  • 2
    this is one situation where qualifying with a namespace makes sense and is a good use of it people. But otherwise add using statements at the top of your classes and do not fully qualify if you do not have to. – PositiveGuy Oct 19 '12 at 21:16
14

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.

jrista
  • 32,447
  • 15
  • 90
  • 130
  • 1
    @CoffeeAddict: It depends on what your goals are. If good performance is a key requirement, sometimes you have to "muddy the pure waters" of what might otherwise be an "ideal" architecture in order to improve performance for things that go over the wire. If you have the luxury of not using service-oriented architecture, granular DTO's are not necessary in the first place. – jrista Oct 20 '12 at 01:21
9

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.

BengtBe
  • 4,465
  • 1
  • 26
  • 19
2

I typically append DTO in situations like this.

William Edmondson
  • 3,619
  • 3
  • 32
  • 41