An important part of any data-driven application is ensuring data consistency and handling errors when they occur. Ensuring data consistency requires a combination of data input. Validation means ensuring that any user input meets the application's expectations for what that data should contain. Whenever dealing with data, errors can occur at a number of levels, and you need to be prepared to deal with those errors in a way that minimizes the impact on users and yet ensures the consistency and correctness of the data.

Validation is all about checking input from the user and making sure it is valid, based on some criteria that you, as the application designer, determine. Examples of validation checks include:
• Checking for required input in a particular field
• Checking whether input data is a valid numeric value
• Checking for input to be within some range of values
• Checking for particular patterns within an input string
• Invoking complex business rules that check dependencies between other business entities and values in your application


Validation can and should occur at multiple levels in a large application. The first line of defense is to check the input from users at the point where they are entered it the winform. However, in a large application, that data is often passed down into a business layer and/or data access layer through some remote technology such as a Web service. There could be any amount of intervening code through which the values have to pass before they are persisted to a data store. Data validation should occur when the user inputs data, when the data is submitted from the winform application into the middle tier that provides the business services for that application.

How much intelligence is embedded in the presentation tier (Windows Forms) application is a design decision, but in general, in layered application architecture, you want to keep your presentation layer or tier as thin as possible. You will want to enforce validation checks at the winform level that are relatively invariant, but defer complex checks that may vary over time to the business layer. Regardless of how much validation logic you put at the winforms level, there is a rich infrastructure built into Windows controls and winforms to allow you to perform the checking that you need when you need it.

This section describes the mechanisms that a winform application based on koossery.MVCwin can use inorderto perform validation of data that are intered in the winform by user. Those mechanisms are built on top of the .NET Framework for dealing with validation and error handling.

Providing Error Information with the IDataErrorInfo

The logic of a winform based on koosery.MVCwin framework is that all data that has to be displayed on a view (for instance LoginView) are in a simple data-bound class xxxViewData (for instance LoginViewData) that extends AbstractBaseData.

According to our example, you may want to have xxxViewData be responsible themselves for determining what is valid data and what is not. For example, if you have a LoginViewData class, that class could contain logic that determined what a valid Login is, or what a valid Password is. According that, there need to be a standardized way for data-bound objects to notify data-bound controls when there is a validation error at the object level.

The IDataErrorInfo interface is designed exactly for this scenario. If the individual data data-bound object implements the IDataErrorInfo interface, then data-bound controls can use that interface to determine if an error has occurred, what that error is, and which property on the object the error is related to.

The IDataErrorInfo interface has two members: a string property named Error, and an indexer (named Item) that takes a string parameter and returns a string. The parameter takes a property or column name within the data object and is expected to return an error corresponding to that property, if there is one.

As an example, we add validation logic to the LoginViewData class. Specifically, We add some checking on the Login and Password property to prevent a null value from being entered.
The listing 1 shows the validation logic

public string Login  
{
	get { return login; }
	set 
	{
          if (string.IsNullOrEmpty(value))
          {
              this["Login"] = "The Login should not be null";
          }
          else
          {
              login = value;
                    //Raising the PropertyChanged Event
		  PropertyHasChanged("Login");
           }			    
	}
}

public string Password
{
	get { return password; }
	set 
	{
           if (string.IsNullOrEmpty(value))
           {
               this["Password"] = "The password should not be null";
           }
            else
            {
                password = value;
                //Raising the PropertyChanged Event
                PropertyHasChanged("Password");
             }
	}
}

If the Login that is entered by the user is null, the property set block sets the error text for the Login property, and these errors will be detected by the LoginView control bound to an instance of the LoginViewData object when that property value is exceeded through the IDataErrorInfo implementation.
All ViewData contains a private dictionary of per-property error messages. The dictionary is the filled and can be useful for data bounded controls.
The figure below shows the running LoginView with the errors kicking in.

ValidationIDataErrorInfo.PNG

In the figure above the boxes are bound to a BindingSource component that is bound to the LoginViewData. There is also an ErrorProvider control on the form that is bound to the same BindingSource with the error provider's DataSource property. When a user tries to type in a null Login, the property set block assigns the corresponding errors within the object. The property set block also raises the PropertyChanged event, which signals any bound controls to check for errors. The bound controls use the IDataErrorInfo interface to look for errors for any properties they are bound to on the object, as well as an error at the object level itself. If errors are found, the bound controls can update their displays accordingly.

Last edited Jun 19, 2009 at 5:48 PM by mohamadou, version 4

Comments

No comments yet.