Regarding validation I don’t really see that this scenario creates an additional problem. Typically I treat validation is a screen level concern (at least when there are screens involved!). I don’t like this but with another approach you need a way to map errors back to fields and I have not determined a good way to do this. I don’t like the ASP.NET validation controls (especially from a testability POV) but they do solve the problem.

Note that the previous paragraph is all theory as I have not yet tackled DTO validation…but that will change today (if I ever stop responding to comments!). I’ll do a follow up post on what happens.

Regarding the additional repository method I am not completely comfortable with this either. I am a firm believer in avoiding premature optimization. As I indicated in the original posting my concern about DTOs is that they were superfluous because they didn’t add value. I don’t expect that I will use them all the time, just where necessary. It remains to be seen how often this turns out to be.

It seems like in this scenario calling the customer a DTO has implications, especially if you were to apply it to a larger enterpise (which you were clearly not, but I cant help myself!). One I can think of is Validation, which would fall on the CustomerDTO since it is more or less bound to the view. Another is that we have created a repository method which returns a CustomerDTO specifically for the behavior of this view.

Would you do it different in a greenfield enterprise scenario? Again, very cool stuff.

To me thats an interesting approach — its been drilled into me, and I’ve taken it as gospel that the database and back-end whatevers all need to come before the screens. How well does this approach work in comparison? I can see some huge opportunities here, but on the flip side people older and wiser than me have said differently.