Unless I'm missing something (which is very possible), it seems to me that custom validation has always violated DRY. In all the examples I've seen, even with the brand new Unobtrusive Client Validation introduced w/ MVC 3, we have to create .NET code for our server-side validation, and jQuery (or JavaScript code) for client-side validation.
I understand that there's no such thing as a .NET-to-jQuery translator that would facilitate DRY server/client validation, and I guess that would be the only way to have true DRY validation that works both server and client side.
But I would be perfectly content with having custom validation always performed on the server. The data needed to pass into custom validation (in my case) is usually limited to one or two fields, and the server-side logic is usually pretty quick, even if it has to hit the database.
Is there no OOTB mechanism for wiring up custom validation using attributes, then having your client side validation use Ajax to execute the validation server-side and respond to the client? Or, has someone come up with such a solution?
Or is it a matter of, in the end, the tradeoffs of repeating the custom validation is better than the issues introduced w/ always executing custom validation server side?
Thanks in advance.
OOTB: http://msdn.microsoft.com/en-us/library/system.web.mvc.remoteattribute(v=vs.98).aspx
You aren't really validating DRY here. The concept of DRY is a bit more nuanced than simple duplication of code. There are acceptable tradeoffs, especially when coupling concerns are taken into account.
When people ask this question, which is quite often if you search around, I usually refer them to the DDD concept of bounded concepts. Using [Remote] and forcing DRY when it comes to validation tends to bunch up tons of concerns in one place and merging the responsibilities of several layers. Business Logic vs. Persistence and Data Integrity Logic ( non nulls ).
@Darin Dmitrov says it pretty well in a lot of his answers he's made to this exact question. Validating that a required field is filled in is much different from making sure Sally has enough credit to make a purchase and should be treated much differently.
Client validation is best used for basic concerns and not be overloaded with more heavy operations. The impact on usability from client validation is really minimal. There is nothing "unusable" about posting a form and waiting for a refresh. It is more fluent but not anything that will make or break the success of your application.
AFAIK, there is nothing OOTB (Out Of The Box).
As for the tradeoffs - though violating DRY, you gain several things:
- Immediate feedback to the user (improved usability)
- No round tripping in case of validation errors (less load on server)
Of course, apart from violating DRY and opening yourself to those issue, you also end up with a larger payload to the client (extra javascript).
No one can tell you whether these tradeoffs are worth it - you need to decide what is right for your application, users and client.
I don't really share your concerns about violating the DRY principle in this case, but it looks like a couple other people have already discussed that.
However, your idea sounds a lot like the new remote validation feature that was added with MVC 3:
How To: Implement Remote Validation in MVC3
On the other hand, nothing is stopping you from having all of the built-in simple checks performed on the client side, and doing all of the heavy custom validation only when posting back to the server.
