How to Validate ASP.NET Web Forms Using a Business Rules Engine

A Brief Intro Into Web Form Validation

As you know, the purpose of an HTML form is to deliver user input from the client to the server. One of the purposes of web applications is to make sure that the incoming data is valid, safe, and ready for further processing. This is called "input validation". The process of input validation can be divided into three steps:

1. Format validation. For example, the server needs to make sure that fields don't contain any unsafe values, that the required fields have data, that values of different types can be safely converted into those types, etc. Normally, format validation is done by validation controls.

2. Conversion of received string values into typed values. For example, if the form accepts loan applications, the incoming data needs to be converted into some kind of a loan application object where the string "annual gross income" would be converted into GrossIncome property of type System.Decimal.

3. Optional validation of business rules against strongly typed data. For example, the server must make sure that annual income is larger than the total debt and that the applicant has been employed for the last 5 years.

The first two steps are well documented and understood. They are almost always required and can be automated by using common or custom tools and controls, at least to some degree. But the third step is not that simple. A lot of developers I know are absolutely sure that they never use business rules in their web forms. And most of them are wrong. The reason is simple: we often mix format and rule validation in one statement without realizing it. Of course, some small forms don't use business rules at all. But it's rather an exception from the rule. Consider the following code:

DateTime test;

if(txtLastEmployed.Text.Length == 0 ||
    !DateTime.TryParse(txtLastEmployed.Text, out test) ||
    test < DateTime.Now.AddYears(-5))
{
        DisplayWarningMessage("The date of last employment is either empty, or has invalid format, or is in the past of limit.");
}

In this example, the first condition is format validation, the second is type conversion, and the third is evaluation of a business rule. It's easy to see that the first two conditions will never change, unless the LastEmployed property gets removed from our imaginary data object. But the third condition is not guaranteed to stay the same forever. The way it's written, if tomorrow the business owner changes the 5 years term to any other number, we will have to compile, test, and deploy the entire application all over again just because of this tiny change.

Of course, we can always store condition values in configuration files. For example, the following snippet would demonstrate such an implementation:

try
{
    // some code
}
catch(Exception ex)
{
    if (ConfigurationManager.AppSettings["Production"] == "true")
    {
        LogException(ex);
        DisplayAnExcuse("Sorry, we screwed up!");
    }
    else throw ex;
}

Read more: Codeproject
QR:

Posted via email from Jasper-net