C＃ - 执行验证的位置

Question

I have a question about when to validate inputs on C# form applications.

When taking inputs from a form application, you can run all the validation as you parse in the data from the text fields in the main form class, to then use wherever. For example:

Method 1:

class Car
{
    private string registration { set; get; } // NO VALIDATION HERE
}
// in the form class
private void add_Click(object sender, EventArgs e)
{
    // get registration
    int reg_valid = Validate.registration(txtReg.Text); // VALIDATION IS DONE HERE

    if(reg_valid)
    {
        Car.registration = txtReg.Text;
    } else {
        // Registration invalid - throw error
    }
}

There will be no validation in the actual Car object as it is all done in the form class.

The other way is to validate the input in the actual class it is stored in like:

Method 2:

class Car
{
    // out registration
    private string registration;

    // we can set our registration here and return false if there is an error
    bool set_registration(registration)
    {
        int reg_valid = Validate.registration(registration); // VALIDATION IS DONE HERE

        if(reg_valid) {
            this.registration = registration;
        } else {
            return false; // if error
        }

        return true; // if all goes well
    }
}
// in the form class
private void add_Click(object sender, EventArgs e)
{
    // get registration
    string registration = txtReg.Text; // NO VALIDATION DONE HERE

    // we can then store this in our object
    if( ! Car.set_registration(registration))
    {
        // Registration invalid - throw error
    }
}

Method 1 seems cleaner, but one of the reasons why we use private attributes is so that we can validate any parsing arguments which is why method 2 seems the better option. Also, using method 2, errors have to be carried up the stack possibly many times, which leads to repeated if statements.

* Please note, this code has not been ran so may contain errors.

Answer 1

You should have a Core of classes and also those classes related to the user interface. First, create the Core classes (the bussiness logic ) of your application. Of course, you should do validation here. Actually, code as if you had no knowledge about who is going to implement the user interface. Also, take into account that users interfaces can change, while the core classes should remain untouched.

When coding the user interface, you wil realise that if you don't do any validation, exceptions will be raised when the user inputs some data cases. This will make you create validation also in the user interface classes.

So, the answer is, you will finally have validation on both parts of the application.

Answer 2

Caution : Opinion-based answer !

It depends on the requirements of the Project, its scale , and the time you have (and many other factors of importance like "User Friendly Application" or of no importance like "my own taste would be.." )

Due to the wide range of possible cases per individual, the answer cannot be expressed in a general guideline which would fulfill the needs of everyone .

Your question addressed two objects to manipulate :

• one Form used as an User Interface where the user can input anything (assumption defined by "the user enter *any* value then click a Button" )
• a Class Property that is fed with the value (Setter) when it's valid.

---

• You have no time , requirements just tells "Input a value", this is a small task in the Project of no critical importance on a small class used within this Button, and you're very lazy :

  => In Button Click, make a rigid validation with one or two forbidden checks that whip out any non allowed value, and shows a MessageBox depending on the nature of the Error. Only pass a Value to the class and go further when you have a valid value.

.

• You have no time , simple requirements, small task of no critical importance but with a class largely used , but you're lazy :

  => Move the validation above in the class then Throw one, two or three generic Exceptions with custom messages. In any UI action using that class, use Try/Catch to capture the exception in the ButtonClick and display a MessageBox without going further in case of captured Exception.

.

• You have 5 minutes , simple requirements, small non critical task, important Class role :

  => Like previously but, decide whether another way to show user is more recommended (depending of your target users) like changing the background color of a TextBox after you click a button, displaying the message in a Label, instead of annoying the user with a dialog box...

.

• You have 10 minutes , simple requirements, repetitive task , important Class role :

  => Find a way to quickly test a given value and creates a public or friend (static ?) function in your Class that returns the result of a validation attempt, like an UICarValidationEnum Enumeration (* see Edit below) of possible Validation Errors :
  a) UICarValidationEnum.Valid
  b) .TooLong
  c) .NullValue
  d) .ForbiddenChars
  e) ...
  You can then use that validation Function inside and outside your Class. That way, you can handle invalid Setter attempts both before performing the Setter and while performing it , aswell as both using you class along with UI and without . The drawback is you can't avoid double validation if you check if the data is valid outside the class (In your Button for eg.)

.

• Time matters , but requirements is efficient inputs , repetitive task of great importance, class largely used - you can't be lazy :

  => Handle both UI Validation and Class Validation. Why ? The UI Part addresses the "efficient inputs" part, and the Class Part addresses the "role of the Class". You can use the Validator Function above, or implement much more Exceptions upon Setter like in the other cases above. You're increasing the number of handled Exceptions/Invalid inputs by providing much more information to the user upon Button Click.
  Remember : Class largely used. The move here is to implement the maximum coding to handle different cases of invalid inputs, to reduce the amount of code to write elsewhere in your project while still be able to handle all those cases.

.

• Time matters , User Friendly Application, repetitive task, important Class :

  => Reconsider the UI Layout and behaviour, validation is mainly UI, but Class is still doing it by itself :
  a) User hates Dialog Boxes (whatever DialogBox, message, openfile, etc.. avoid them whenever possible)
  b) User hates aggressive colors
  c) User hates validation
  d) ...... User hates a lot of things..!

  The role of the Function Validation above is of importance here : Capture the User Input actions. If it's a TextBox for example, capture the TextChanged Event, then call the Class validation Function. Update information in a Label notifying any encountered error, and change the background color of the TextBox to a friendly color, but related to an error standard, like light Pink. Don't use Color.Red, that's too agressive for most users. Seeing Red 200 times a day can lead to unexpected behaviours at the end of the day.
  Only enable the Button when ALL Inputs are valid. Don't make a button per input, User hates endless validations.

.

• Time doesn't really matter , User Friendly Application, repetitive task, important Class :

  => Along with the previous option, improve UI response.
  Add graphic icons in your label, and/or consider the use of an ErrorProvider in your Form. Users like simple icons rather than long similar messages.
  Consider the use friendly sounds to notify poping errors (not everyone is "kind of visual receptive" )

.

• Time doesn't matter at all , User Friendly Application, repetitive task, important Class :

  => Keep capturing user inputs live, but implement suggestive corrections related to. If it's a TextBox, use AutoCompleteCollection with predefined and fixed Inputs suggestions in the collection when user attempts to input invalid Datas (you'll need a Function for that).
  Live disable other inputs when they are incompatible with user's choices/actions.

.

• Time really matters , User Friendly recommended, repetitive task, important Class :

  => Don't overload your Form with validations routines.
  Create a Custom Control for that specific Input. Overload your custom control with the validations. If your class cannot be used outside this UI, don't bother creating validations inside. Move everything in your custom Control and, even forbid invalid chars (if it's a textbox) whenever possible. In this specific case, you're going to use the UserControl as the Validator component of your Datas.
  Otherwise, use the Class validating Function scheme upon Input and display the appropriate error in an User Friendly way whenever possible through that user Control (case where your Class may be used without the UserControl, which would generally be the case)

---

Etc. etc. etc.

I know I'm more considering the user who's going to use the Application than the one who's going to write the code. But have a look at Baltasarq's answer . In fact, best move is to do both. The three first options are there only for a simple Class of no real importance in your whole Project. We've all created that tiny Class to begin with, and we didn't bother to make strong validation controls. I think that most of us still use those kind of classes. However, as times goes by, some of those classes become more and more used.. then we were faced to the need of stronger validations schemes.

That's the cutting corners way . It's unsafe, but it works... until something happens...

=> Try to do both whenever possible. You don't know what may happen, who is going to use your Class, whether your boss will change his mind and ask you to create a specific UI for that Class to be user friendly for everyone...

Since a while, when I have time upon creating a Class, I'm in fact creating at least two classes :

- MyClass_Class
- MyClass_Form
- (and perhaps MyClass_UserControl )
- (and perhaps MyChildClass WithUnsafeSetters - used to set value that has already been validated for performance needs)

The core class always provide live Validation capabilities...

---

EDIT :

Property Validator Function sample using enums...

[Flags]
public enum registrationValidation_Enum
{
    Valid = 0x01,
    TooLong = 0x02,
    InvalidChars = 0x04,
    NullEntry = 0x08
    // ...
}

This enum can be encapsulated within the class. Enums are easier to handle/memorize/retrieve than Exceptions Classes.

This is the Property Getter/Setter.

class Car
{
    private string registration = "Unknown";

    public string Registration
    {
        get
        {
            return registration;
        }
        set
        {
            validate_registration(value, True);
            // Setter for the Property.
            // Throws an Exception upon invalid value.
        }
    }
}

This is a Validator Function which is Public :

    public registrationValidation_Enum test_registration(
        string newRegistration)
    {
        registrationValidation_Enum checkResult =
            registrationValidation_Enum.Valid;

        // Do the checks here
        if (newRegistration.Length > 10)
        {
            checkResult = checkResult | registrationValidation_Enum.TooLong;
        }
        if (containsNonAlphNumericChars(newRegistration))
        {
            checkResult = checkResult | registrationValidation_Enum.InvalidChars;
        }
        // ...
        return checkResult;
    }

And here is the Public version of the Setter :

    // this bypass the double check : attempts to set the value if Valid.
    // otherwise, either returns a validation result,
    // either throws an exception.
    public registrationValidation_Enum validate_registration(
        string newRegistration,
        bool canThrowException)
    {
        bool isValid = test_registration(newRegistration);
        if (isValid == registrationValidation_Enum.Valid)
        {
            registration = newRegistration;
            return registrationValidation_Enum.Valid;
        }
        else
        {
            if (canThrowException)
            {
                string exceptionMessage = "";
                if (isValid | registrationValidation_Enum.TooLong)
                {
                    exceptionMessage += "Registration too long" 
                                     + Environment.NewLine;
                }
                if (isValid | registrationValidation_Enum.InvalidChars)
                {
                    exceptionMessage += 
                        "Registration contains invalid characters"
                        + Environment.NewLine;
                }
                // ....
                Throw New Exception(exceptionMessage);
            }
            else
            {
                return isValid;
            }
        }
    }

The public validate_registration(string, false) is there in case :

• you don't want to double the validation upon Button Click
• you don't live monitor the user Inputs
• you don't want to handle cascading exceptions everywhere
• you want have control over custom error messages per UI context (you can't always have a label to write errors in)
• while attempting to set registration value, all in a row with a button click.

Put the validation result in a variable in any UI-side and display the appropriate notifications/users choices depending on the UI components you can display... This wouldn't have been that simple with Exceptions : Imagine you have both TooLong and InvalidChars. Are you going to show a dialogbox "Too Long" then click button then show another "Invalid Chars" dialog ?

Note : To make the class Localizable , with custom Exception messages using Culture, I would define Class Level Messages (string) variables which values depend on the loaded Culture.

Answer 3

You would use public properties with private members, where you do the checking inside the properties and then assign it to class members.

class Car
{
    private string registration;

    public string Registration 
    {
        get { return registration;}
        set { 
                if(Validate.registration(value))
                    registration = value;
                else
                    throw new Exception("Your exception message here");
            }

    }
}

private void add_Click(object sender, EventArgs e)
{
    Car.Registration = txtReg.Text;
}

Answer 4

There are 2 validations:

• data type/property limits/parsing;
• logical (values between properties);

Have a look at PropertyGrid . It's basic (and pretty sufficient) validation is if your property accept value or throw:

class Car
{
    private int _someValue;
    public int SomeValue
    {
        get { return _someValue; }
        set
        {
            if(value > 100)
                throw new OutOfRangeException(...);
            _someValue = value;
        }
    }
}

This ensures what Car can validate own properties no matter how they are set (deserialization, PropertyGrid , direct property value, reflection, etc).

Another thing is some logical validation, which can't be performed at instance level, or you simply don't care about it (let instance to be created without exceptions). This one has to be put into editor code (form what is used to create instance).

As for myself, talking about TextBox , I prefer to make custom MyTextBox control which has all parsing related validation (methods GetDouble() , GetInt() , GetIntTime() , etc) and possibility to setup/query it (properties IsDouble , IsInt , etc.).