UI Validation best practices

Topics: CAB & Smart Client Software Factory
Feb 6, 2007 at 6:57 AM
Hi everyone,
I have a question about UI validation on smart part. I have the usercontrols implementing the MVP model. The forms that have been presented to the end user need to be validated before an appropriate action is taken on them. How would I go about doing it

1) Should I do validations on the Control and contact the presented only for BL and services
2) Should I do all the validations on the presenter and invoke the view with a message that needs to be displayed?

If 2 is the suggested solution, how would I go about generically displaying message to the end user if something was wrong on the form.


Feb 6, 2007 at 7:07 AM
You could add a text box on the SmartPart and update it with the validation fault from the presenter.
You could also use a message box (See MessageBoxService) for more info on displaying a message box from the presenter.

I've got a validation problem as well, but I will post mine in a separate thread as it's a bit different.

Good luck,
Feb 6, 2007 at 7:23 AM
Hi Sklett,
So, if I understand right, however trivial the validation is, the best practice is to
go to the presenter. I will look into the MessageBoxService now

Cheers & thanks
Feb 6, 2007 at 7:49 AM
Hey Raj,

No, I don't think that is a best practice, it's just an option. I'm in no position to suggest what is a best practice as I am STILL trying to learn the correct ways to do things.

I was only suggesting a possible solution. I handle certain validation in the View, or I should say certain validation TASKS. EG: If a user enters a value in a DataGridCell I check with the presenter if the value is unique, if not I cancel out of the edit event for the Grid.

Something like (pseudo code)
//  In the view's CellValidating event
e.Cancel = _presenter.IsUniqueSN(serialNumber);

Notice I'm reacting to the validation result in the View, but doing the validation in the Presenter. I think this is a good way, but I'm not sure. Maybe we will both learn something if one of the pros chimes in with some suggestions.

Feb 6, 2007 at 10:25 AM
I think I will go with validating in the presenter, I think it will keep the code base consistent (with regards to interaction with presenter). Its a good idea to wait and see if the pros have any suggestions.


Feb 6, 2007 at 4:02 PM
Take a look at the new EnterpriseLibrary 3.0 Validation Block. It solves this problem quite nicely by allowing validation rules to be housed with your business object. You can then use an ErrorProvider at the UI level and hook it into your validation rules on your business object. It keeps your UI layer thin and puts the validation logic where it belongs - in the business code.
Nov 9, 2010 at 7:38 PM

What I do in my case is a little bit more complex but very loosely coupled and match the MVP pattern.

First of all you need to decide where the validation should go. In my opinion it is a presentation logic concern, so it should go in the Presenter. In this way I can recycle the validation logic for the future. Of course you to architect a solution to display the messages in the View and invalidate the View iteself.

This is the pseudo code I use with the Ent. Lib. 5 VAB:

    public interface ILoginView : IViewISmartPartInfoProvider
        void ShowError(Expression<Func<ILoginViewstring>> propertystring error);

In this case the View is only in charge of display the error. What I do is to display the error in the view using a reflection tool I built. A control should have in the TAG
property the name of the property is bind to ... Smart and easy as I don't want to use the bind engine of Windows Form.

In the presenter the validation can be called at any time, based on specific presentation logic requirements, like here:

        private bool IsViewValid()
            if (string.IsNullOrEmpty(this.View.Username))
                this.View.ShowError(v => v.Username"The Username can't be null or empty.");
                return false;

            this.View.ShowError(v => v.Usernamestring.Empty);
... ....

In this way, you can put this code in a WPF app and it still works without changing the presenter.

My two cents.