Liskovs Substitution Principle

I’m a big fan of patterns and principles. And I’m going explain all SOLID principles in different blog posts. This post is all about LSP.

LSP says that you should always be able to use a base class or interface instead of the actual implementation and still get the expected result. If you can’t, your breaking LSP.

An example:

public interface IDuck
{
   void Swim();
}
public class Duck : IDuck
{
   public void Swim()
   {
      //do something to swim
   }
}
public class ElectricDuck : IDuck
{
   public void Swim()
   {
      if (!IsTurnedOn)
        return;

      //swim logic  
   }
}

And the calling code

void MakeDuckSwim(IDuck duck)
{
    duck.Swim();
}

As you can see, there are two examples of ducks. One regular duck and one electric duck. The electric duck can only swim if it’s turned on. This breaks LSP since it must be turned on to be able to swim (the MakeDuckSwim method will not work as expected if a duck is electric and not turned on).

You can of course solve it by doing something like this:

void MakeDuckSwim(IDuck duck)
{
    if (duck is ElectricDuck)
        ((ElectricDuck)duck).TurnOn();
    duck.Swim();
}

But that would break Open/Closed principle (SOLID) and has to be implemented everywhere (and therefore still generate instable code).

The proper solution would be to automatically turn on the duck in the Swim method and by doing so make the electric duck behave exactly as defined by the IDuck interface.

The solution with turning on the duck inside the Swim method can have side effects when working with the actual implementation (ElectricDuck). But that can be solved by using a explicit interface implementation. imho it’s more likely that you get problems by NOT turning it on in Swim since it’s expected that it will swim when using the IDuck interface.

What LSP is really saying is that all classes must follow the contracts that they have been given. Just as you may not update items in your website with GET if you are following the HTTP protocol.

HtmlHelper for enums in ASP.Net MVC3

Have you tried to get enums working with HtmlHelpers? It can be a hassle and here is my solution for it. It requires that you tag each entry in the enum with a [Description] attribute.

public static class SelectExtensions
{

    public static string GetInputName<TModel, TProperty>(Expression<Func<TModel, TProperty>> expression)
    {
        if (expression.Body.NodeType == ExpressionType.Call)
        {
            MethodCallExpression methodCallExpression = (MethodCallExpression)expression.Body;
            string name = GetInputName(methodCallExpression);
            return name.Substring(expression.Parameters[0].Name.Length + 1);

        }
        return expression.Body.ToString().Substring(expression.Parameters[0].Name.Length + 1);
    }

    private static string GetInputName(MethodCallExpression expression)
    {
        // p => p.Foo.Bar().Baz.ToString() => p.Foo OR throw...
        MethodCallExpression methodCallExpression = expression.Object as MethodCallExpression;
        if (methodCallExpression != null)
        {
            return GetInputName(methodCallExpression);
        }
        return expression.Object.ToString();
    }

    public static MvcHtmlString EnumDropDownListFor<TModel, TProperty>(this HtmlHelper<TModel> htmlHelper, Expression<Func<TModel, TProperty>> expression) where TModel : class
    {
        string inputName = GetInputName(expression);
        var value = htmlHelper.ViewData.Model == null
            ? default(TProperty)
            : expression.Compile()(htmlHelper.ViewData.Model);

        return htmlHelper.DropDownList(inputName, ToSelectList(typeof(TProperty), value.ToString()));
    }

    public static SelectList ToSelectList(Type enumType, string selectedItem)
    {
        List<SelectListItem> items = new List<SelectListItem>();
        foreach (var item in Enum.GetValues(enumType))
        {
            FieldInfo fi = enumType.GetField(item.ToString());
            var attribute = fi.GetCustomAttributes(typeof(DescriptionAttribute), true).FirstOrDefault();
            var title = attribute == null ? item.ToString() : ((DescriptionAttribute)attribute).Description;
            var listItem = new SelectListItem
                {
                    Value = ((int)item).ToString(),
                    Text = title,
                    Selected = selectedItem == ((int)item).ToString()
                };
            items.Add(listItem);
        }

        return new SelectList(items, "Value", "Text");
    }
}

Usage:

@Html.EnumDropDownListFor(m => m.SubscriptionMode);

If you want to be able to use it for validation, you need to be able to have a “undefined” entry in your enum and do the following change:

// replace "Value = ((int)item).ToString()," in to select list.
Value = (int)item == 0 ? string.Empty : ((int)item).ToString(),

The art of creating exceptions

This will be my final piece on exception handling. It’s been fun, but the show must go on, right? Got any suggestion on what I should rant about in this blog? Leave a comment.

Please take a moment and think about WHY you throw exceptions.

You done? Have you come up with a reason? You are probably thinking: “That b!@tch is a total moron. I throw exceptions to know that something exceptional have happened!”. If that is the case, please stop reading here. (The first part of the thought is totally fine by me, I can be a total moron.)

.
.
.
.
.
.

I SAID STOP READING!!!!

.
.
.
.
.
.
.

Really!

.
.
.
.
.
.
.
.
.

No? Well. Ok then. Want to be an exception master? Got some ninja skills? Have you bought a jump suit? I have actually created a diploma (yes, It’s true) that I will email to anyone who leave a comment that says: “I throw exceptions to be able to try to prevent them in the future”. Because that’s what you should really try to do. Sure, some exceptions that are thrown CAN’T be prevented. But a lot of them can.

Let’s take FileNotFoundException as an example. It can in MOST cases be prevented, if you are not a lazy SOB, by checking if the file exists before trying to open it. The exception can STILL be thrown if the file is deleted between the check and and you opening it. Life is harsh, isn’t it.

The problem is that if you do not provide any contextual information you will have a hard trying to prevent it in the future.

Instead of just writing

  throw new FileNotFoundException("Ohhh, the file was missing! *buhu*");

do write

  throw new FileNotFoundException(string.Format("Failed to find '{0}'.", amazingFileName));

Even better would have been if you could add some more context and add the filename as a parameter:

  throw new FileNotFoundException(string.Format("User photo for user #{0} was not found", userId)) { Filename = amazingFilename };

That gives a lot more information to work with, don’t you think? When designing exceptions you should ask yourself “What kind of context information can I provide in this exception to make it easier to prevent it?”. Regarding a file it’s quite obvious. Hence I would design the exception like this:

  public class FileNotFoundException : IOException
  {
      public FileNotFoundException(string message, string fileName)
	     : base(message)
	   {
			Filename = fileName;
	   }

       // *ALWAYS* include a constructor which takes a inner exception.
	   //
	   // I WILL HUNT YOU DOWN AND GIVE YOU SOME SPANKING IF YOU DON'T!
       public FileNotFoundException(string message, string fileName, Exception inner)
		: base(message, inner)
	   {
	   }

      public string Filename { get; private set; }
  }

Let’s look at another example.

I’ve talked about a DataSourceException in previous posts. It could be used to report problems in the data layer (regardless of the type of data source). The first thing that comes into my mind is that we have a target and some parameters. When using a web service, the target is the URI and the parameters are anything posted. Likewise, for SQL the target is a SQL query and the parameters is the parameters used in the SQL query. Doing it like this creates a potential security risk. Do NOT expose exception details for the end users, never ever.

  public class DataSourceException : Exception
  {
	public DataSourceException(string message, string target, Dictionary<string, object> parameters)
	     : base(message)
	{
			Filename = fileName;
	}

       public FileNotFoundException(string message, Exception inner, string target, Dictionary<string, object> parameters)
		: base(message, inner)
	{
	}

	public string Target { get; private set; }
	public Dictionary<string, object> Parameters { get; private set; }

  }

How it can be used for a webservice request:

	try
	{
		var user = myWebSvc.GetUser(userId);
		if (user == null)
		  throw new InvalidOperationException(string.Format("Failed to find user #{0}", userId)); //kilroy was here
	}
	catch (WebException err)
	{
	    throw new DataSourceException(string.Format("Failed to download user.", userId), myWebSvc.Uri, userId);
	}

Or for a database:

	string errMsg = "Failed to update user";
    ExecuteCommand(cmd => {
		cmd.CommandText = "UPDATE user SET name=@name WHERE id=@id";
		cmd.AddParameter("name", name);
		cmd.AddParameter("id", userId);
	}, errMsg);

Where did all code go? It’s a small method looking like this:

	public void ExecuteCommand(Action<IDbCommand> action, string errMsg)
	{
		// CreateConnection() uses DbProviderFactory and
		// throws DataSourceException if connection fails
		using (var connection = CreateConnection())
		{
			var cmd = connection.CreateCommand();
			try
			{
				action(cmd);
				cmd.ExecuteNoQuery();
			}
			catch (DbException err) //notice that I only handle DbException?
			{
				// WTF is this? Check next code snippet.
				// note that I *return* an exception from the extension method (instead of throwing it)
				throw cmd.ToException(errMsg, err);
			}
			finally
			{
				cmd.Dispose();
			}
		}
	}

I used a small extension method:

    public static class DataExtensions
	{
		public static Exception ToException(this IDbCommand command, string errMsg, Exception inner)
		{
			var parameters = new Dictionary<string, object>();
			foreach (var p in command.Parameters)
				parameters.Add(p.ParameterName, p.Value);
			throw new DataSourceException(errMsg, inner, command.CommandText, parameters);
		}
	}

Summary

You should be fine if you stop to think “I throw exceptions to inform that something exceptional happens” and instead start thinking “I throw exception to help try to prevent the exceptional cases from happening in the future”. Having that mindset helps you create much more detailed exception classes (and hopefully also provide that information).

Each time you are about to throw an exception ask yourself: What information can I provide in this method to make it easy to find out why the exception was thrown? It might take a couple of minutes longer, but how long does it take to debug your application if you do NOT get that information? Usually a lot longer.

Action points for you:

  1. Create exception classes containing as much context information as possible
  2. Always create a constructor that takes an inner exception
  3. Throw exceptions to help prevent them in the future
  4. Try to include as much context information as possible

Update

Hold the presses. I got so carried away by my bright ideas for this article that I got a bit blinded by the brightness. The most important reason to a throw exception is to be able to handle it. That’s why you throw DataSourceException and not Exception. The more specific, the merrier.

Common mistakes when working with exceptions

There are a few mistakes that’s really common when it comes to exception handling and I though that I should write a small entry about them.

Rethrowing and destroying the stacktrace

This is a evil one. Because it’s really easy to use it and the compiler do not complain about it (it should be easy to spot by the compiler). The code also looks correct if you don’t know what it really does.

What am I talking about?

    try 
    {
        FutileAttemptToResist();
    }
    catch (BorgException err)
    {
         _myDearLog.Error("I'm in da cube! Ohh no!", err);
        throw err;
    }

Looks about right? The problem is the throw err; part. It will wipe the stack trace and create a new one from your catch block. You’ll never know where the exception originated from. Just use throw;

Using policies for exception handling

I’ve started to write several pieces about why you should not use policies (for instance Exception Handling Block in Enterprise library) but I never got really satisfied with it.

The problem with the block is that the examples is still not very good and really tricks you into bad practices.

Anyway, introducing policies can be good if you are following my guidelines in the post “Do NOT catch that exception!”. The problem though is that it’s easy to start adding try/catch/policy everywhere and hence producing unreadable code that is logging the exception multiple times again.

Just handle those exceptions that you can handle. No need for a policy.

Not including original exception when wrapping

Another common mistake is to not include the original exception when throwing another one. By failing to do so, you are also failing to give information about where the error really happened.

    try
    {
        GreaseTinMan();
    }
    catch (InvalidOperationException err)
    {
        throw new TooScaredLion("The Lion was not in the m00d", err); //<---- original exception is included, hooray!
    }

Not providing context information

This one is actually a golden rule at Microsoft. They really love to give us developers a challenge when something fails. They have built a superior framework with .Net and they need to put us developers back to earth sometimes. Hence the crappy exception descriptions.

This is what I’m talking about:

    try
    {
       socket.Connect("somethingawful.com", 80);
    }
    catch (SocketException err)
    {
        throw new InvalidOperationException("Socket failed", err);  //I LOVE InvalidOperationException. Read my previous post.
    }

What’s wrong? The exception message is just stating the obvious. We already know that the connect fails. But we do not know what it tried to connect to. Always provide contextual information. NHibernate is the glorious king when it comes to developer friendly exceptions. Examine it’s source code and learn something.

what you really should do is something like this:

    void IncreaseStatusForUser(int userId, int newStatus)
    {
        try
        {
             var user  = _repository.Get(userId);
             if (user == null)
                 throw new UpdateException(string.Format("Failed to find user #{0} when trying to increase status to {1}", userId, newStatus));
       
             user.Status = newStatus;
             _repository.Save(user);
        }
       catch (DataSourceException err)
       {
           var errMsg = string.Format("Failed to find modify user #{0} when trying to increase status to {1}", userId, newStatus);
            throw new UpdateException(errMsg, err);
       }

I always try to include as much information as possible in my exceptions. One could discuss if that sensitive information should not be included in exceptions. But I say YES! It’s really up to code that EXPOSES the exception (for instance a logger or a message box) to hide sensitive information. For instance, only log exceptions in a log that the correct people have access to. Exceptions should be dealt with ASAP anyway.

I would never expose a exception to a end user. What use do they have of the exception information? You got a widely used application and need to get exception information? Encrypt it and upload it to your server (with permission from your user of course).

Simplified localization for DataAnnotations

Update

I’ve come up with a better localization method for MVC3. Read about it here.

Original article

The built in localization support in DataAnnotations is a bit hard to work with. You are supposed to do add the ResourceManager to each attribute that you add. The code is looking like something like this:

    public class User
    {
        [Required(ErrorMessageResourceName = "Validation_Required", ErrorMessageResourceType = typeof(ModelTranslations))]
        public int Id { get; set; }

        [Required(ErrorMessageResourceName = "Validation_Required", ErrorMessageResourceType = typeof(ModelTranslations))]
        [StringLength(40, ErrorMessageResourceName = "Validation_StringLength", ErrorMessageResourceType = typeof(ModelTranslations))]
        public string FirstName { get; set; }

        [Required(ErrorMessageResourceName = "Validation_Required", ErrorMessageResourceType = typeof(ModelTranslations))]
        [StringLength(40, ErrorMessageResourceName = "Validation_StringLength", ErrorMessageResourceType = typeof(ModelTranslations))]
        public string LastName { get; set; }
    }

You should of course move the strings to a static class or something like that.

The problem is that you have just added translation for the validation messages and not the actual model. There are actually no built in solutions for that problem.. If you google, you find some solutions using a custom LocalizedDisplayNameAttribute that uses the same approach as the DataAnnotationAttribute’s: Pointing on a resource type in the attribute constructor.

Updated source code for this solution:

    public class User
    {
        [Required(ErrorMessageResourceName = "Validation_Required", ErrorMessageResourceType = typeof(ModelTranslations))]
        [LocalizedDisplayNameAttribute("User_Id", NameResourceType=typeof(ModelTranslations))]
        public int Id { get; set; }

        [Required(ErrorMessageResourceName = "Validation_Required", ErrorMessageResourceType = typeof(ModelTranslations))]
        [StringLength(40, ErrorMessageResourceName = "Validation_StringLength", ErrorMessageResourceType = typeof(ModelTranslations))]
        [LocalizedDisplayNameAttribute("User_FirstName", NameResourceType=typeof(ModelTranslations))]
        public string FirstName { get; set; }

        [Required(ErrorMessageResourceName = "Validation_Required", ErrorMessageResourceType = typeof(ModelTranslations))]
        [StringLength(40, ErrorMessageResourceName = "Validation_StringLength", ErrorMessageResourceType = typeof(ModelTranslations))]
        [LocalizedDisplayNameAttribute("User_LastName", NameResourceType=typeof(ModelTranslations))]
        public string LastName { get; set; }
    }

Not very readable, is it? As you can see, I use the pattern ClassName_PropertyName for all strings definitions. It’s a safe way to avoid a name collision. The same word might not mean the same thing in different models.

The solution

What we need is a way to provide strings to all attributes WITHOUT specifying the resource in the attribute constructors. In this way we can easily move resources without having to change each attribute. Changing every attribute is not very DRY is it?

My solution is to create a singleton class that you can fetch strings from. Want a more flexible solution? Check my ShureValidation library (shameless advertising) that I’ve posted about earlier in this blog.

End result for the model:

    public class User
    {
        [Required]
        [LocalizedDisplayNameAttribute("User_Id")]
        public int Id { get; set; }

        [Required]
        [StringLength(40)]
        [LocalizedDisplayNameAttribute("User_FirstName")]
        public string FirstName { get; set; }

        [Required]
        [StringLength(40)]
        [LocalizedDisplayNameAttribute("User_LastName")]
        public string LastName { get; set; }
    }

A bit more readable? oooooh yes *uhu*.

Classes making it possible:

You have to derive all standard DataAnnotation attribute classes like this:

    public class RequiredAttribute : System.ComponentModel.DataAnnotations.RequiredAttribute
    {
        private string _displayName;

        public RequiredAttribute() 
        {
            ErrorMessageResourceName = "Validation_Required";
        }

        protected override ValidationResult IsValid(object value, ValidationContext validationContext)
        {
            _displayName = validationContext.DisplayName;
            return base.IsValid(value, validationContext);
        }

        public override string FormatErrorMessage(string name)
        {
            var msg = LanguageService.Instance.Translate(ErrorMessageResourceName);
            return string.Format(msg, _displayName);
        }
    }

Next step is to add a custom DisplayName class:

    public class LocalizedDisplayNameAttribute : DisplayNameAttribute
    {
        private PropertyInfo _nameProperty;
        private Type _resourceType;

        public LocalizedDisplayNameAttribute(string className, string propertyName)
            : base(className + (propertyName == null ? "_Class" : ("_" + propertyName)))
        {

        }

        public override string DisplayName
        {
            get
            {
                return LanguageService.Instance.Translate(base.DisplayName) ?? "**" + base.DisplayName + "**";
            }
        }
    }

And finally create the language service:

    public class LanguageService
    {
        private static LanguageService _instance = new LanguageService();
        private List<ResourceManager> _resourceManagers = new List<ResourceManager>();

        private LanguageService()
        {
        }

        public static LanguageService Instance { get { return _instance; } }

        public void Add(ResourceManager mgr)
        {
            _resourceManagers.Add(mgr);
        }

        public string Translate(string key)
        {
            foreach (var item in _resourceManagers)
            {
                var value = item.GetString(key);
                if (value != null)
                    return value;
            }

            return null;
        }
    }

You can easily switch to a database or something like that if you need to.

Update

A follow up entry showing how to fix client-side validation in MVC3 can be found here.

InvalidOperationException: “Exception” in disguise? Or just the new ApplicationException?

Microsoft added ApplicationException with the idea that all exceptions that you made should derive it. Fair point, your should be able to handle your own exceptions, right? The problem is what nobody used it and therefore Microsoft changed it’s recommendation to NOT use it. It’s just lying there in the framework like an old aunt that just don’t want to go away (I still love you all my dear aunts).

InvalidOperationException is also an exception that should be blown to hell. The description of the exception says this:

The exception that is thrown when a method call is invalid for the object’s current state.

What does that mean in the real world? When do exceptions get thrown in general? Well. When something unexpected have happened, as in when a method is called when it isn’t supposed to be. How else can an exception be raised? When not calling a method?

The InvalidOperationException is really like an Exception in a disguise. Try to search in a couple of open source projects after it (or your own). It’s thrown a lot. It’s a poor mans choice to exception handling. Ohhh, I’ve been guilty one too many times too. It’s so handy since it can be applied to all exceptional cases.

The reason to why I wrote this post is that I was debugging an ASP.Net MVC application and found that MS throws it when an action cannot be found in a controller. The result is that a Internal Server Error page is shown instead of a File Not Found page. Sure, it’s an error in the application and the proper controller have been found. But do the browser care about which framework is used in the web server? No. File not found is therefore the proper status code.

Microsoft should have created an ActionNotFound exception instead and derived it from HttpException (and set the 404 status code in the constructor initialization).

Edit:
I’ve filed a bug report for ASP.Net MVC: http://aspnet.codeplex.com/workitem/7588

Why autogenerated mstests is bad for you!

ms can generate complete test classes for you that test and access all methods and properties, no matter if they are private or public. Isn’t that awesome? Well no.

Let me do a statement first: I’m not fond of auto-generated code, no matter what it is for.

Why? Because writing code makes you think. You’ll have a better chance to find design error earlier than if you get a lot of stuff generated for you. You also need to know how stuff works. If everything is auto-generated for you, you don’t have to care. Right?

Back to mstests.

Reason 1:
The access to private/protected members/properties is bad for you. If you can’t manage to test those methods/properties through the public API it’s most likely that they can’t be called from your regular application either. Either remove the code that you can’t test or refactor the class.

Reason 2:
The  generated test classes includes one test per method. Inexperienced unit testers might think that it’s enough with one test per method: They either just write one test or includes all the different tests in the same test method. Both of those options make it a lot harder to test and get robust applications.

Reason 3:
Readability.The generated tests is harder to read:

(i’ll post samples here later)

Conclusion: Build all your tests by yourself (it makes you think about your design once more). Remove code that you can’t test through the public interface (or refactor).

Do NOT catch that exception!

Ohhh, I’ve recently seen one to many application where the developers try to be safe by catching exceptions all over the place. It can be everything from a small simple method that doesn’t throw that many exceptions to a large method with multiple try/catch statements. Most of those catch blocks just logs the exception and rethrow it.

This post discusses how those problems can be solved.

Ohhh, I’ve recently seen one to many application where the developer try to be safe by catching exceptions all over the place. It can be everything from a small simple method that doesn’t throw that many exceptions to a large method with multiple try/catch statements. Most of those catch blocks just logs the exception and rethrow it.

Please do not catch that exception. Let it travel down the call stack. I promise you that you won’t regret it. You’ll get a warm and fuzzy feeling next time you’ll test your application. I promise you! Really!

Why? You’ll get a complete exception with all the details you need to fix the error, it’s very easy to loose information if you catch/wrap/rethrow exceptions . The problem with all of those try/catch blocks is they doesn’t help your application in any way. They just clutter up the code and your log files.

If you still want to catch exceptions: I’ll try to explain the way to do it.

Catching exceptions in the correct way.

Yeah. Proper exception handling can be something wonderful. You’ll smile every time you get an exception. First of all: Exceptions only happens when something exceptional occurs.  Please have that in mind, because it helps you remember that you don’t need those try/catch block everywhere.

That brings us to the golden rule about when to catch exceptions:

Only catch exceptions that you can handle to rescue the situation.

That means that you should only catch exceptions if you, by handling it, can let the application continue as (almost) expected. Let me rephrase that: Only catch a exception if you, by catching it, can let the method return a result as promised.

There are of course exceptions, namely two of them:

Do not let layer specific exceptions propagate up the call stack.

For instance, if the data layer fails and throws a SqlException (if you are using Sql Server) you should catch it and wrap it inside a more generic exception. Create a DataSourceException which could be used even if you switch data source from a database to a Web Service. You should of course add details to the exception such as the method name, parameters or anything else that can be useful. Do NOT forget to add the original exception as  inner exception.

public class UserRepository : IUserRepository
{
    public IList<User> Search(string value)
    {
        try
        {
              return CreateConnectionAndACommandAndReturnAList("WHERE value=@value", Parameter.New("value", value));
        }
        catch (SqlException err)
        {
             var msg = String.Format("Ohh no!  Failed to search after users with '{0}' as search string", value);
             throw new DataSourceException(msg, err);
        }
    }
}

Update 2013-03-01: I’m not following this rule any more. The only time I wrap exceptions is if I add more context information to help me prevent the exception in the future. It doesn’t really matter if the data layer exception is passed up the call stack, since it won’t be handled but just logged in the top layer

If you don’t want to display data layer specific information to the user, then simply display something like "An unexpected error occurred" instead of showing exception information. The exception information doesn’t really help your user either way.

Try/Catch all is OK in the layer closest to the user.

Ok, so you have let the exceptions propagate through all your layers to the presentation layer (winforms/asp.net etc). Fine. Go ahead, give the user some fancy error pages. Also log those errors. But just don’t log them. Notify a support team. Send an email to the project lead.

When everything else fails

Are you not sure that your new exception policy will catch all of those exceptions? Is it scary? The I got the solution for YOU!

Asp.Net Implement Aplication_OnError(object source, EventArgs e) in your global.asa. It will be called for all unhandled exceptions.
WinForms Subscribe on Application.ThreadException
WinServices Subscribe on AppDomain.CurrentDomain.UnhandledException. The problem with this event is that it will still terminate the application. But there’s a way around that too.
WCF WCF: Implement IErrorHandler and log the exceptions in it (added 2013-03-01).
ASMX ASMX: Create a custom Soap Extension. (added 2013-03-01).

In the next blog post I’ll discuss common mistakes in those catch blocks and how your tailor made exceptions should look like.

Update 2013-04-17

I’ve written a new exception series. Starting with What are exceptions?

Introducing a validation library

I’ve made a validation library which is focusing on model validation. Why another one when there are a few good ones like EntLib Validation ApplicationBlock and Data Annotations?

Three reasons:

1. It’s extendable

You can easily extend the library in different ways.

Own validation rules

You can create your own rules in the following way:

[sourcecode language=”csharp”]
public class CoolnessRule : IRule
{
public string Format(string fieldName, IModelLanguage rulesLanguage)
{
return string.Format(rulesLanguage["Coolness"], fieldName);
}

public bool SupportsType(Type type)
{
return type == typeof (string);
}

public bool Validate(object value)
{
return value.ToString() == "Jonas";
}
}
[/sourcecode]

The Format method is used when formatting and localizing error messages. Each rule can be more or less complex and might to add range restrictions etc. Therefore it’s up to the rule to pull the language prompt (in this case “‘{0}’ must be called ‘Jonas’ to be cool“) and add the correct number for parameters.

The SupportsType method is used to determine if the specified type can be validated by the rule. For instance, the Max rule can validate all primitive types and strings (string length).

Validate method does the actual validation.

Validate in different ways

The actual validation can be done in different ways. Fluent and attribute validations are built in, more about them later. To add your own validation provider, do something like this:

[sourcecode language=”csharp”]
class MyRuleProvider : IRulesProvider
{
public bool Contains(Type type)
{
return type == typeof (Model2);
}

public ModelValidator Create(Type type)
{
ModelValidator validator = new ModelValidator();
validator.Add("FirstName", new RequiredRule()); // first name is required
validator.Add("Department", new BetweenRule(5, 20)); // department must be between 5 and 20 letters.
validator.Add("Age", new BetweenRule(18, 65)); // age must be between 18 and 65 years.
return validator;
}
}
[/sourcecode]

The Contains method determines if this provider have support for the specified type. And the Create method is used to create the ModelValidator class containing all the rules.

Then you just need to add your provider to the library:

[sourcecode language=”csharp”]
Validator.Add(new MyRuleProvider());
[/sourcecode]

2. It’s multilingual

The multilingual support is quite flexible too. You can easily load language from any source you want. Myself are using text files to be able to categorize entries and use one file per model (I use the translation files for other stuff too, for instance localized error messages).

To load strings from a StringTable, you can do something like this:
[sourcecode language=”csharp”]
public class LanguageProvider : ILanguagePrompts
{
public string this[string modelName, string promptName]
{
get { return Get(modelName, promptName) ?? "[" + promptName + "]"; }
}

public string Get(string modelName, string promptName)
{
return Resource1.ResourceManager.GetString(modelName + "_" + promptName);
}
}
[/sourcecode]

And to use your provider:

[sourcecode language=”csharp”]
Validator.LanguageHandler = new LanguageProvider();
[/sourcecode]

In your string table you create entries like the following ones:

[sourcecode language=”text”]
User_FirstName FirstName
User_LastName LastName
[/sourcecode]

i.e. ModelName underscore PropertyName

3. It’s flexible

The library doesn’t force you to use validations in a certain way. You can use your own favorite way of creating validations.
The two built in providers use either code or attributes to provide validations.

Attribute validation

[sourcecode language=”csharp”]
public class MyModel
{
[Required]
public string FirstName {get;set;}

[Required, Min(15)]
public string LastName {get;set;}
}
[/sourcecode]

FirstName is required and LastName is required and must be maximum 15 characters long.

Your own validation rules will automatically be added to the validator when using attribute validation.

Fluent validation

Fluent validation means that you create a class which is used to validate models. The class is automatically loaded and instantiated by the library, all you need to do is to create it and place it in the same namespace as the model. It should be named [YourModelName]Validator, i.e. UserValidator.

[sourcecode language=”csharp”]
public class MyModelValidator : FluentValidator<MyModel>
{
public MyModelValidator()
{
Property("FirstName").Required();
Property("LastName").Required().Min(15);
}
}
[/sourcecode]

To add support for your own validation rules, simply create extension methods for the Property class:

[sourcecode language=”csharp”]
public static Property Tired(this Property instance)
{
instance.Add(new TiredRule());
return instance;
}
[/sourcecode]

Usage

The most important part is how the library are used, right?

[sourcecode language=”csharp”]
User user = new User();
user.FirstName = "Jonas";

var errors = Validator.Validate(user);
if (errors.Count > 0)
{
// Handle the errors in any way you like.
// both property names (localized and actual property name) and localized error message is accessible.
}
[/sourcecode]

Source code

The source code can be found at CodePlex.