How to validate DTO's for a Client Server application

Question

I've been doing a lot of reading about DTO's recently, having never used them before. One article I read spoke about how DTO's should not just replicate domain model objects but rather each DTO should be tailored to the service operation being performed.

This got me thinking about validation if I decided to used DTO's and wondered if the following would be acceptable?

public class Person {
    public Guid Id {get; set;}
    public string Name {get; set;}
    public Address Address {get; set;}
}

public class Address {
    public Guid Id {get; set;}
    public string AddressLine1 {get;set;}
    ...
}

publuc class CreatePersonDTO {
    private string _name;
    private string _addressLine1;

    public string Name {
        get {
             if (_name == null)
                 throw new Exception("Missing");

             return _name;
        }
        set { _name = value; }
    }

    public string AddressLine1 {
        get { return _addressLine1; }
        set { _addressLine1 = value; }
    }
}

So you pass your data through in either Json or Xml and it is serialised to the object CreatePersonDTO and when mapping those values to create a Person and Address object if the Persons Name is missing then it will throw a validation exception.

As the DTO itself is service operation specific so is having this validation here ok or is it breaking some kind of rule regarding where business logic should reside?

Answer 1

DTOs should have no validation; they are strictly for transferring data. Beyond validation, they should really have no behavior at all.

If the name is required, that is an aspect either of the domain or of a given service operation; validation should be encapsulated in the corresponding places (though you may also enforce the rule in the UI for a better experience).

Answer 2

I would interpret each DTO should be tailored to the service operation being performed to mean if you have bulky domain objects DTO's can represent a subset that is pertinent to a particular service operation. I.e. it may only be interested in a few properties of the domain object.

Answer 3

That depends. But usually it's not good place to put validation login into DTO. You wil have issue with reusability. For example if you need to update person you will have to create UpdatePersonDTO and put all the same logic there.
As another option you may put your validation logic into Person itself so you will not be able to create invalid person and it will be reusable. Or you may put entities validation logic into some kind of service layer.

Answer 4

You should not put validation logic into your DTOs, this should be handled primarily by your Domain layer and in some cases, duplicated in your UI layer. Your DTOs should be just that, dumb objects to transfer data.

Beyond the separation of responsibilities here, your logic can't actually be serialized. The only things that would be transferred over the wire are the values themselves. If you were passing this object to a non .NET consumer (over WCF for example) then they would not necessarily have the same rules built into the object that they deserialize the data into.