Custom MVC 3 and DRY Verification

Question

If I am missing something (which is very possible), it seems to me that conventional validation always violated DRY. In all the examples I've seen, even when using the new version of Unobtrusive Client Validation introduced by w / MVC 3, we need to create .NET code for our server-side validation and jQuery (or JavaScript code) for the client-side validation.

I understand that there is no such thing as a .NET-to-jQuery translator that would facilitate a quick check of a DRY server / client, and I assume that this is the only way to have a true DRY check that works both on the server side and on the client side.

But I would be completely pleased that a user check was always performed on the server. The data needed to go to user verification (in my case) is usually limited to one or two fields, and the server-side logic is usually pretty fast, even if it gets into the database.

Is there an OOTB mechanism for connecting custom validation using attributes, and then client-side validation uses Ajax to perform server-side validation and client response? Or did anyone come up with such a solution?

Or is this a question, after all, the tradeoffs of repeating a user check are better than the problems that arise with / always performing the user side of validation?

Thanks in advance.

Answer 1

OOTB: http://msdn.microsoft.com/en-us/library/system.web.mvc.remoteattribute(v=vs.98).aspx

You really don't check DRY here. The concept of DRY is a bit more subtle than just duplicating the code. There are acceptable trade-offs, especially considering communications considerations.

When people ask this question, which is quite common during a search, I usually attribute them to the concept of DDD for limited terms . Using [Remote] and forcing DRY when it comes to verification tends to collect a ton of problems in one place and combine the responsibilities of several layers. The logic of business logic and the constancy and integrity of data (without zeros).

@Darin Dmitrov says this is pretty good in many of the answers he gave to this exact question. Confirming that the field is completed is very different from making sure that Sally has enough money to make a purchase, and she needs to be treated differently.

Client validation is best used for basic problems and not overloaded with heavier operations. The impact on usability from customer verification is really minimal. There is nothing unsuitable for publishing a form and waiting for an update. This is more free, but not something that will make or break the success of your application.

Answer 2

AFAIK, there is nothing OOTB (out of the box).

Regarding trade-offs - although it violates DRY, you get a few things:

• Immediate user feedback (improved usability)
• No cyclic shutdown in case of verification errors (less load on the server)

Of course, in addition to breaking DRY and discovering this problem, you also get a big payload for the client (additional javascript).

No one can tell you if these trade-offs are needed - you need to decide what suits your application, users, and client.

Answer 3

I really do not share your concerns about violating the DRY principle in this case, but it seems like a couple of other people have already discussed this.

However, your idea sounds just like the new remote verification feature added with MVC 3:

A practical guide. Implement Remote Validation in MVC3

On the other hand, nothing prevents you from performing all the built-in simple checks performed on the client side and performing all the heavy selective checks only when sending them back to the server.