...lungi da me ;-), ma... ebbene si secondo me c'è sempre un ma.

In questo periodo, decisamente massacrante, stiamo lavorando ad una soluzione potenzialmente abbastanza complessa e potenzialmente molto distribuita ;-) quindi uno dei problemi è che abbiamo n tier che vengono coinvolti dal ciclo di vita di una entity o da una operazione di business; e questo mi fa sempre dire che ogni tier/layer è storia a se, non sa nulla di chi sta prima e sa molto poco di chi sta dopo... e se assieme a questo assioma ci mettiamo che il dato è sacro (meglio un service unavailable che una information disclosure, qualcuno disse: "it sucks, but it sucks less") allora è facile asserire e sostenere che, ad esempio, i controlli sulla validità del dato in ingresso devono essere fatti a qualsiasi livello e siccome uno di questi livelli è il database io ce li metto pure li.

.m

<update>
A seguito del commento di Igor forse è giusto che faccia un approfondimento. Quando dico che il dato è sacro intendo dire che è sacro per ogni tier a modo suo. Ogni tier ha una sua visione del dato e ha un suo modo per ritenerlo valido, quindi ha una sua logica di validazione che è decisamente diversa da tier a tier. Questo significa che se la business rule dice che il "Cognome" non deve essere più di x caratteri è un problema applicativo e al db non interessa minimamente mentre al db ad esempio interessa e molto che il dato che arriva non corrompa lo consistenza dei dati che già sono presenti, e di certo un Cognome troppo lungo non corrempe un bel nulla ;-)

Un'altro apsetto fondamentale di tale logica è ad esempio la validazione dei parametri/argomenti di un metodo, come lo faccio nel mio codice C# lo faccio anche nel codice T-Sql. E qui non c'è santo che tenga se una enumerazione può assumere 3 valori devo controllare che quello che arriva sia consistente.

Dipende tutto dal punto in cui ci si trova a guardare il flusso.

Resta il fatto che se hai un'applicazione distribuita devi prevedere che ci possa essere il "furbetto" che cerca di chiamarti direttamente il servizio WCF passando dei dati malformati solo per il gusto di vederlo schiantare.

per quel che riguarda infine le business rules tendo a centralizzare molto, una cosa del tipo:

IServiceContainer sc = ServiceContainer.GetContainer();
using( IValidationService svc = sc.GetService<IValidationService>() )
{
    IValidationContext ctx = MyEntityValidationContext( entity, action, bla, bla, bla );
    IValidationResult result = svc.Validate( ctx );
}
</update>