I wrote a couple weeks back on my attempt to re-write the ValidatableBase class I wrote for Universal Windows Apps. The original idea was great, but in practice it turned out to be a headache. Writing a method per property (in some cases more than one!) really bloated the code and made it difficult to read. So I set out to tackle this in a different way.
To demonstrate the improvements, I want to first revisit how the previous version worked. The following is a simple User model that would perform validation on a user name and password with the old ValidatableBase.
public class User : ValidatableBase
{
private string email = string.Empty;
private string password = string.Empty;
public User()
{
this.RegisterProperty("Email", "Password");
}
public string Email
{
get
{
return this.email;
}
set
{
this.email = value;
this.OnPropertyChanged("Email");
}
}
public string Password
{
get
{
return this.password;
}
set
{
this.password = value;
this.OnPropertyChanged("Password");
}
}
public override void Validate()
{
this.ValidateProperty(this.ValidateEmailIsNotEmpty, "Invalid Email Address.", "Email");
this.ValidateProperty(this.ValidateEmailIsFormatted, "Email Address is not in the correct format.", "Email");
this.ValidateProperty(this.ValidatePasswordIsNotEmpty, "Password can not be empty.", "Password");
this.ValidateProperty(this.ValidatePasswordIsToShort, "Password must be greater than 8 characters.", "Password");
this.ValidateProperty(this.ValidateIfPasswordContainsSpaces, "Password must not contain spaces.", "Password");
base.Validate();
}
private IValidationMessage ValidateEmailIsNotEmpty(string failureMessage)
{
if (string.IsNullOrEmpty(this.Email))
{
return new ValidationErrorMessage(failureMessage);
}
return null;
}
private IValidationMessage ValidateEmailIsFormatted(string failureMessage)
{
string[] addressParts = this.Email.Split('@');
if (addressParts.Length < 2)
{
var msg = new ValidationErrorMessage(failureMessage);
return msg;
}
string[] domainPiece = addressParts.LastOrDefault().Split('.');
if (domainPiece.Length < 2)
{
var msg = new ValidationErrorMessage(failureMessage);
return msg;
}
return null;
}
private IValidationMessage ValidatePasswordIsNotEmpty(string failureMessage)
{
if (string.IsNullOrEmpty(this.Password))
{
return new ValidationErrorMessage(failureMessage);
}
return null;
}
private IValidationMessage ValidatePasswordIsToShort(string failureMessage)
{
if (this.Password.Length < 8)
{
return new ValidationErrorMessage(failureMessage);
}
return null;
}
private IValidationMessage ValidateIfPasswordContainsSpaces(string failureMessage)
{
if (this.Password.Contains(' '))
{
return new ValidationErrorMessage(failureMessage);
}
return null;
}
}
As you can see, I had to write a single method for each different type of validation I wanted to perform. In this case, as shown in the Validate() method, I have 5 different methods to validate 2 properties. Imaging a more complex model? This quickly turned in to a messy model.
The solution
I heavily modified the ValidatableBase class and its interface initially, but ultimately ended up being able to keep it mostly unchanged and just add on to it. The validation via method delegates certainly has a place, and I didn't want to loose that. The goal this time-around however was to make delegates the last choice instead of the first choice.
The class now supports attribute based validation, very much like Microsoft's DataAnnotation. Since Data Annotations are not supported in Universal Apps, I set out to build my own version, which actually ended up being a bit different with some nifty features.
Let's take the User class, and re-write it to use the new validation scheme.
public class User : ValidatableBase
{
private string email = string.Empty;
private string password = string.Empty;
[ValidateValueIsNotNull(FailureMessage = "E-Mail can not be left blank.", ValidationMessageType = typeof(ErrorMessage))]
[ValidateWithCustomHandler(DelegateName = "ValidateEmailFormat")]
public string Email
{
get
{
return this.email;
}
set
{
this.email = value;
this.OnPropertyChanged("Email");
}
}
[ValidateStringIsGreaterThan(GreaterThanValue = 6, FailureMessage = "Password must be greater than 6 characters.", ValidationMessageType = typeof(ErrorMessage))]
[ValidateStringIsLessThan(LessThanValue = 20, FailureMessage = "Password must be less than 20 characters.", ValidationMessageType = typeof(ErrorMessage))]
public string Password
{
get
{
return this.password;
}
set
{
this.password = value;
this.OnPropertyChanged("Password");
}
}
[ValidationCustomHandlerDelegate(DelegateName = "ValidateEmailFormat")]
private bool ValidateEmailIsFormatted(IMessage failureMessage)
{
string[] addressParts = this.Email.Split('@');
if (addressParts.Length < 2)
{
return false;
}
string[] domainPiece = addressParts.LastOrDefault().Split('.');
if (domainPiece.Length < 2)
{
return false;
}
return true;
}
}
Now we are down to just a single method that performs validation. The Email property has two validation attributes, a ValidateValueIsNotNull and a ValidateWithCustomHandler attribute. The value is not null attribute is self explanatory, it just ensures the value isn't null and progresses. The ValidateWithCustomHandler allows you to specify a delegate name that you want th validator to use when performing validation. You'll notice that there no longer needs to be a method within the model called Validate() as this is part of the base class and handles invoking all of the validation attributes, and their custom handlers if they exist.
We use validation on the Password property as well, by ensuring it meets the minimum and maximum length requirements we define.
A really cool feature of this, is the ability to perform validation based on other property values. For instance, let's assume that validation for the Password can only fire when the Email property has a value set. If that is the case, then we just modify the Password attributes to specify that the Email property must be valid in order for our validation to fire.
[ValidateStringIsGreaterThan(GreaterThanValue = 6, ValidateIfMemberValueIsValid = "Email", FailureMessage = "Password must be greater than 6 characters.", ValidationMessageType = typeof(ErrorMessage))]
[ValidateStringIsLessThan(LessThanValue = 20, ValidateIfMemberValueIsValid = "Email", FailureMessage = "Password must be less than 20 characters.", ValidationMessageType = typeof(ErrorMessage))]
public string Password
{
get
{
return this.password;
}
set
{
this.password = value;
this.OnPropertyChanged("Password");
}
}
As you can see here, by setting the ValidateIfMemberValueIsValid, the validation will only get fired if the Email property is not empty or null. What if we wanted to have validation fire only if the Email property was empty? We can do that be prepending an exclamation mark in from of the string representation of the Email property.
ValidateIfMemberValueIsValid = "!Email"
This works with boolean values by checking if it is true or false, floats, doubles, ints, longs, shorts and decimals by checking if they are zero or not along with empty strings and null objects.
Finally, the method delegate feature still exists, and can be used by external objects to enforce additional validation on the model. Let's use a view model as an example. Assume the view model has a PasswordConfirmation property, that must equal the users Password before user creation validation is considered acceptable. We can do the following in our view model, within a CreateUser method or an ICommand.Execute method.
public void Execute(object parameter)
{
// Perform validation on the user's built in validation.
this.AppUser.ValidateAll();
// Piggy-back on top of the user default validation with an additional level of validation in our view model.
// We ensure the password and password confirmation matches.
this.AppUser.ValidateProperty(
() => PasswordConfirmation.Equals(this.AppUser.Password),
new ErrorMessage("Passwords do not match!"),
"Password");
// Check if there are any errors.
if (this.AppUser.HasValidationMessages<ErrorMessage data-preserve-html-node="true">())
{
return;
}
// Do stuff.
return;
}
Here, we fire the user validation off, then we piggy-back on it by creating our own validation via an anonymous method, and assigning it to the "Password" property of the user. If validation fails, it will be added to the Users validation message collection. We then check if the user has any validation error messages. If they do, we abort the user creation.
The API still has a bit of tightening up to do before I can upload it, but it should be ready before the end of the week on GitHub. It's taken a bit of time due to ensuring that what I end up here can run properly. I managed to wire it up in to the latest build of the Mud Designer engine tonight which will really help with development.