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.
I am exposing DTO to my clients. I have below questions
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?
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?
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
Having DTO at times seem redundant to me but i can use it to club details from one or more entities.
I would be exposing this service to various client and thus my DTO will be deriving from some base dto having credential details which i would check for each incoming request before my actual wcf method call (probably using IEndpointBehaviour and IParamInspector)
Edit
Based on the response I kind of now agree to retain the DTO layer, Here is an exmaple so that scenario become more explicit
Say I have CreateCustomer method accepting CustomerDetailsDTO in my WCF Application Service Layer which may be called by an MVC application.There are some input validations like
Input Validations:
i)Name length should be greater than 2 but less than 50 ii) Age is mandatory and cann not be less than 18 (Different other field validations)etc
Business Validations:
There could then be some business rules to check for dupliate customer
based on say email or some other factor whcih i think should be part of
my Domain business logic and should reside in CustomerEntity class.
Should Input Validation be only applied at service interface layer as we get DTO from client
or it should also be applied on CustomerEntity
Best Answer
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.
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
ArgumentNullExceptionin 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.
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
Agestruct, wrapping anUInt32(thus the input rule before). Why wrap anUInt32? 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 oneMortalPrescription, 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).