Should DTO and Entity both have input validations

Question

I have a WCF layer and my Domain Model is behind this WCF layer. I am using Nhibernate as an ORM tool and all my business logic/ Data Access etc will be behind this WCF layer.

Answer 1

1) Should i create DTOs? is there any harm in exposing entities directly to wcf clients as my entities would also have business logic methods also in doing so i would have to corrupt my entitiy object with WCF attributes which i think is not good?

Yes, SOA requires data contracts.

They can be more or less formalized (CSV, JSON, XSD, WSDL, WADL even HTML or a txt file) but if you can't find an agreement on such contracts, you shouldn't adopt any "service" technology or technique (nor any other IPC for what it matter).

Remoting was the only technology that tried to avoid such requirement. It was an amazing idea, in abstract, but concretely it didn't work.

2) If i expose DTO, should i be validating DTO as well as Entity. If i validate only DTO then i am not providing any input validations for my Enitity object . is this ok?

You should validate the "contract", not the business rules.

For example a WCF DTO can require some fields to be populated, and I would use ArgumentNullException in the constructors.

But you should remember that DTOs serve to transfer data. If you have a numeric field that for some strange reason have to be transferred as a string, you can validate it, for example preventing the inizialization of the DTO.

3) Should i consider validating the DTO in the Application Service layer (WCF layer) using Schema validation? or Should i use IValidator Approach given in article [blog]: http://lostechies.com/jimmybogard/2007/10/24/entity-validation-with-visitors-and-extension-methods/ as shown by Jimmy Bogard

If you need a domain model (that means that you need to hire an expert to understand the application purpose), it has to be the only responsible for business rules. Thus for simple validations, you shouldn't need any validation framework.

What you need are expressive exceptions that can be mapped easily to properly defined faults.

edit to answer the new questions

In WCF, I often use input validation in the DTO constructors, so that the client can not send "invalid requests". This has many advantages, for example the client can't use invalid input to configure a DOS attack, for example. Moreover if you have a large number of clients this can reduce the network load, and make the user experience a bit better since he doesn't need to wait for a server response just to know that he forgot a the @ in an email field.

But actually being older than 18 is a business rule, not an input rule.

An input rule could be: "the Age field must be greater than Zero", because negative age are not possible, and a zero age sound too much like an user error (and it is the int32 default value).

However contract validation is not enough.

If the age is relevant in your domain you will have a Age struct, wrapping an UInt32 (thus the input rule before). Why wrap an UInt32? For example because in your domain model you know that the sum of two users's age has no meaning.

Yes, you check that number at most 3 times (one on the client and two on the server), but that's the right thing to do, here. The DTOs could evolve indipendently of the domain model, and a domain model cannot risk unexpected behaviour (or you don't need a domain model at all).

To get an idea of a business rule, think of a medical record application that keep track of some specialized kind of therapy: the command void Prescribe(Age patientAge, AntibioticPrescription prescription) could check both the patientAge argument to be greater than the previous prescription's age. That's a business rule. Another business rule should check for dangerous interactions between the current prescription and the previous one.

If so, this command should document and throw 3 exceptions:

• ArgumentNullException, when the prescription is null (assuming it's a reference type)
• InconsistentAge, when the patientAge provided is lower than the last one
• MortalPrescription, when such prescription could kill the patient.

Such exceptions express preconditions that are business rules (except the argument null, that is there to fail as fast as possible when programmers introduce some kind of bugs).