LocalDTOdesign21 October 2004 (Update at end.) If you've been keeping an eye on my fellow ThoughtBloggers you'll know that it seems one of my fowlbots has blown a fuse, the Australian sun obviously frizzles these Swedish models. Jon's annoyed with Data Transfer Objects, but it's not that DTOs are a bad thing, just like any pattern they are useful in a certain context Patterns always have two parts:.. the how and the when not just do you need to know how to implement them, you also have to know when to use them and when to leave them alone He does have a point -. although I only talk about them in the context of remote interfaces, I did not reiterate their remote context in the write up of the pattern itself - and I do run into people who like to use them in non-remote cases So here's my chance to make up DTOs are called Data Transfer Objects because their whole purpose is to shift data in expensive remote calls They are part of implementing... A Coarse Grading Interface Which A Remote interface needs for performance. Not just do you not need them in a local context, they are actually harmful both because a coarse-grained API is more difficult to use and because you have to do all the work moving data from your domain or data source layer into the DTOs. Some people argue for them as part of a Service Layer API because they ensure that service layer clients are not dependent upon an underlying Domain Model. While that may be handy, I do not think it's worth the cost of All of this data mapping. as my controlor randy staford sign in p of eaa "don't underrestimate the cost of [using dtos] .... it's significant, and it '
