All Validation Techniques in ASP.NET MVC

Authors and editors: Sergey Khalipsky, Aleksandr Sliborsky
In the first article (Validation Techniques Comparison) we just considered the most useful and the best techniques that could be used for validation implementation in ASP.NET MVC.
We don’t want to deprive you of a pleasure of doing all this by yourself, so we will just give you a direction and some samples of implementation and let you dig deeper .
So, today’s agenda is:

1. Manual validation in Model Binder and Controllers (client validation type 1 and server validation type 1)
2. DataAnnotations (client validation type 2, server validation type 2);
3. Custom Validation engine implementation (client validation type 1, server validation type 2);
4. Spring Validation Framework usage on a server, manual validation on a client (client validation type 1, server validation type 3)
5. Spring Validation Framework usage on a server, DataAnnotations + manual validation on a client (it’s a mix from several points from previous review);
6. xVal Validation Framework

Let’s start

ASP.NET MVC WebForms vs Spark View Engines. Part 2. Markup

In my previous article (ASP.NET MVC WebForms vs Spark View Engine. Part 1) I had started to describe the differences between standard ASP.NET MVC View Engine and spark. In this short article I will just show the differences between implementation of 3 equal pages.
So, less words, more code…

Tester-analyst

This idea was appeared in my head earlier but I thought that it was wrong. Many thank to Olga Gerasimenok for helping me to understand that it's not bad.

So, we propose that periodically (say - one time per 2-3 weeks) business analyst should quickly test the system and review whether the functionality is implemented correctly not from functional point of view but from "business requirements" side.

We think it's necessary because nor tester neither developers don't understand how it should be really implemented completely right. On development side only business analyst understand it right, on other side - only customer (and even not always) understand it. But rare customer will review the functionality so often and in full measure. So this duty rest on analysts' shoulders.

I've experimented with this one time. Analyst said - "it was really right solution to do this test! Good job!"

So, I think we will continue to apply this practice.