Consider an ASP.NET MVC 2 web application project that uses EF4 POCO entities and the repository pattern to store information in a SQL Server database. So far there are 3 projects, 4 if you count the database:
1.) Domain.dll, has no dependencies, exposes POCO's and repository interfaces.
2.) Storage.dll, depends on Domain, implements repository interfaces (using EF 4).
3.) Mvc.dll, depends on both #1 and #2, provides UI layer.
4.) SQL Server database + connection, dll agnostic (no dependencies).
Let's say I add another web application to host a WCF Data Service, which provides an OData feed of the database using Domain.dll and Storage.dll:
5.) Provider.dll, depends on Domain & Storage, provides OData service layer.
Where does the domain validation logic belong in this solution? If the domain POCO classes are decorated with validation attributes, does the WCF data service need anything else to protect the data? Is it ever a good/bad idea to put validation logic into stored procedures, and why?