Datatable column/row field validation

Question

0.00/5 (No votes)

See more:

I am creating some typed DataTables that I will need to perform validation on the rows and individual cells and have been trying to figure out the best way to design this that will provide flexibility for new validation methods. Some of the fields/columns can have more than one validation methods that needs to be checked.

String field is less than or equal to X (x can change depending on the data column)
String field contains ':' and each string between the colon is less than or equal to X and the entire string is less than Y
String field can not start with a number
Combination of three fields length in a data row can not be greater than X characters.
Date field must be between X and Y dates
Double field maximum of X decimal places

So for example, an EmployeeRow may have string fields of FirstName, MiddleInitial, LastName with maximum length of 25, 5, and 25, but with a total combined of 40 characters and a HireDate field that must be between 01/01/1901 and 12/31/2099.

What I have tried:

I was thinking of setting up a static class for each of the validation rules that returns a struct that has the validation results (boolean) and string message (why validation failed):

C#

public static class ValidationRules
{
    public static ValidationResult MaxLengthValidation(this string value, int maxLength){ // }
    public static ValidationResult MultiPartMaxLengthValidation(this string value, int maxPartLength, int maxTotalLength){ // }
    public static ValidationResult DateRangeValidation(this DateTime value, DateTime minDate, DateTime maxDate) { // }
    // etc..
}

I could then setup my DataRow to have a Validate function that would test each of the columns, as well as implement any multi column validation. Somehow this doesn't feel like it's the best approach, though. Are there any better designs or ways to set this concept up?

Posted 6-Jul-17 10:13am

hpjchobbes

Updated 6-Jul-17 10:37am

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Wendelius · Accepted Answer · 2017-07-06T10:37:00

You can use different approaches for different validations. When defining the data table I'd suggest using constraints whenever possible. This would ensure that the data in the data table is never invalid what comes to the constraint logic.

However, only a few checks can be done using constraints, such as mandatory, foreign keys, range checks etc. This means that you also need to code different validations logic. To react to problems as soon as possible you can validate the data upon column or row change. Have a look at Validate data in datasets[^]

The third category is more complex, especially circular validation that cannot be enforced all the time. In the middle of a modification you may have an invalid situation but in the end you must prevent such data from being entered into the system. This would mean that you may also need to do a separate validation before saving/committing the changes. This kind of validation typically must be fired only when the changes are being persisted so it often requires information from outside the data table (or set). For example you may need to fire this validation only when save button is hit or in some similar situation.