2

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.

Jerad Rose
  • 15,235
  • 18
  • 82
  • 153
  • http://stackoverflow.com/search?q=[asp.net-mvc]+DRY+validation – John Farrell Feb 26 '11 at 22:19
  • @jfar - I actually did that same search prior to posting this, and it seemed like most of those questions centered around the separation of UI validation and business validation. While I originally thought that was mostly unrelated to custom client side vs. custom server side validation, I can see how they can be (and maybe often are) related, as you alluded to in your answer. – Jerad Rose Feb 27 '11 at 01:27

3 Answers3

2

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.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • Yeah, I definitely understand the tradeoffs, but it still seems like the lag and load would both be minimal. I don't know, maybe I'm underestimating it. I would be curious to see benchmarks done on the impact. – Jerad Rose Feb 26 '11 at 21:24
  • @Jerad - And if you have many _thousands_ of concurrent users? You would want _minimal_ load on the server. Of course, if you only have one user and your server is fast, having duplicate logic like that may be overkill. – Oded Feb 26 '11 at 21:26
  • Yeah, like I said, I know there is an impact, and it's compounded the more concurrent users you have. But I currently run a 10-year-old ASP web site that, in some cases, will post back to the server and fetch a completely new page, just to do validation (I know it's horrible, but I did say it was 10-years-old). And while the performance could definitely benefit from more client-side validation, it currently is perfectly capable. I guess I would be happy to start w/ DRY validation, then extend it w/ client-side validation later, if needed. – Jerad Rose Feb 26 '11 at 21:31
  • 1
    @Jerad - Like I said, it depends on different things. If the performance is OK for your application and you don't expect an increased workload that will change that, why change? If it ain't broke don't fix it ;) – Oded Feb 26 '11 at 21:32
1

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.

John Farrell
  • 24,673
  • 10
  • 77
  • 110
  • So in other words, if I'm trying to do validation on the client that requires more complex logic and/or hitting the database, I should question if this even belongs on the client (or presentation layer) to begin with -- is that your point? – Jerad Rose Feb 26 '11 at 22:51
  • @Jerad Rose - In a way. Up to your application. Billy can't buy a stock because he has no money is very important to me and maybe shouldn't be "hacked" ( not really, too harsh of a word but you get the point ) into the UI or V of an MVC app. I don't know if this is too vague but testing if Billy can buy a stock is much different than never allowing Billy to buy a stock if he doesn't have enough money. Does that make sense? ;) – John Farrell Feb 26 '11 at 23:20
  • I'm accepting this as my answer, as it reminded me about `[Remote]`, and that I need to re-think my concerns. – Jerad Rose Mar 01 '11 at 05:24
0

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.

Shea Daniels
  • 3,232
  • 3
  • 23
  • 27