Year: 2015

The Null Object Pattern

Julien Fiaffé Development Practices, Oriented Object Programming , , , ,

empty-frameIn a lot of object-oriented programming languages there is a moment where we have to deal with null pointers/references/objects. These references must be checked to avoid any exception that might end the program in an unexpected way or moment. I think that most of us have encountered this type of error at least once in our lives. Tony Hoare said that the introduction of the null reference is its “billion-dollar mistake”. Yet sometimes it is possible to avoid the use of null pointer in our application by using the Null Object Pattern.

The intent of this pattern is to provide a specific implementation of an abstraction by doing nothing, it is used to replace manipulation of undefined references (null) when it can be and is therefore predictable (again, it does nothing).

I have created the following piece of code, in C#, to show how it can be done.

public class User
{
    public enum NotificationTypes
    {
        Email,
        Text,
        Twitter,
        None
    }
 
    public string Name { get; set; }
 
    public NotificationTypes NotificationPreference { get; set; }
}
public interface INotifier
{
    void Notify(User user, string message);
}
 
public class EmailNotifier : INotifier
{
    public void Notify(User user, string message)
    {
        Console.WriteLine("Hello {0}, {1} - sent by email", user.Name, message);
    }
}
 
public class TextNotifier : INotifier
{
    public void Notify(User user, string message)
    {
        Console.WriteLine("Hello {0}, {1} - sent by text", user.Name, message);
    }
}
 
public class TwitterNotifier : INotifier
{
    public void Notify(User user, string message)
    {
        Console.WriteLine("Hello {0}, {1} - sent by twitter", user.Name, message);
    }
}
 
public static class NotifierFactory
{
    public static INotifier CreateNotifier(User user)
    {
        switch (user.NotificationPreference)
        {
            case User.NotificationTypes.Email:
                return new EmailNotifier();
            case User.NotificationTypes.Text:
                return new TextNotifier();
            case User.NotificationTypes.Twitter:
                return new TwitterNotifier();
        }
        return null;
    }
}
static void Main(string[] args)
{
    var bob = new User { Name = "Bob", NotificationPreference = User.NotificationTypes.Email };
    var john = new User { Name = "John", NotificationPreference = User.NotificationTypes.Text };
    var martin = new User { Name = "Martin", NotificationPreference = User.NotificationTypes.Twitter };
    var jeff = new User { Name = "Jeff", NotificationPreference = User.NotificationTypes.None };
 
    var users = new List<User> { bob, john, martin, jeff };
 
    foreach (var user in users)
    {
        var notifier = NotifierFactory.CreateNotifier(user);
        if (notifier != null)
        {
            notifier.Notify(user, "This is a message");
        }
    }
}

In this example, a message is sent to several users using the notification system they prefer. And they can turn off the notification system by choosing the “None” option and in this case the Notifier instance returned by the factory is null and force us to put a check in the calling code to avoid any NullReferenceException. As you can see, if the Notifier is null there is no particular behavior, this is a sign that the Null Object Pattern might be used. To use this pattern, the first thing to do is to add a new implementation of INotifier:

public class NullNotifier : INotifier
{
    public void Notify(User user, string message)
    {
        // Nothing to do
    }
}

I can now update my factory to return an instance of this new class instead of null:

public static class NotifierFactory
{
    private static INotifier NullNotifier = new NullNotifier();
 
    public static INotifier CreateNotifier(User user)
    {
        switch (user.NotificationPreference)
        {
            case User.NotificationTypes.Email:
                return new EmailNotifier();
            case User.NotificationTypes.Text:
                return new TextNotifier();
            case User.NotificationTypes.Twitter:
                return new TwitterNotifier();
        }
        return NotifierFactory.NullNotifier;
    }
}

Since the Null Object Pattern is stateless, it is common to use it as a Singleton, this is why I used a static field to hold the reference to the pattern. I can now clean the caller code by removing the null check:

static void Main(string[] args)
{
    var bob = new User { Name = "Bob", NotificationPreference = User.NotificationTypes.Email };
    var john = new User { Name = "John", NotificationPreference = User.NotificationTypes.Text };
    var martin = new User { Name = "Martin", NotificationPreference = User.NotificationTypes.Twitter };
    var jeff = new User { Name = "Jeff", NotificationPreference = User.NotificationTypes.None };
 
    var users = new List<User> { bob, john, martin, jeff };
 
    foreach (var user in users)
    {
        var notifier = NotifierFactory.CreateNotifier(user);
        notifier.Notify(user, "This is a message");
    }
}

Now my application has the same behavior as before and is cleaner. With the Null Object Pattern I have been able to remove a check for a null reference in my code without losing any functionality. This pattern may look like a test double but its purpose is not for testing, it’s for production code and match a case of the domain model: in my example the absence of notification is a deliberated choice.

The Null Object Pattern is often used with the Factory pattern (like in my example). You should consider this pattern if you have null check over an abstraction that does not trigger any behavior.

I hope you like this presentation of the Null Object Pattern, and as always do not hesitate to comment.

See you next time!

Dependency Injection and highly coupled objects

Julien Fiaffé Development Practices, Oriented Object Programming , , , ,

power-plugI consider that Dependency Injection (DI) is a very helpful pattern, I love to use it in order to reduce the coupling in my code and it helps me when writing unit tests. But sometimes the code depends on objects that are difficult or impossible to mock.

The HttpContext class of the ASP .NET MVC framework is one example of this kind of object.

I created the following Controller and View as examples:

public class IndexController : Controller
{
    [HttpGet]
    public ActionResult Index()
    {
        string[] languages = HttpContext.Request.UserLanguages;
        return View(model:languages);
    }
}
@model string[]
@{
    Layout = null;
}
 
<!--DOCTYPE html>
 
<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>Index</title>
</head>
<body>
    <div> 
        @foreach (string language in Model)
        {
            @language
            <br/>
        }
    </div>
</body>
</html>

This view displays the languages preferences from the request for the visitor:

languages-preferences

Now, I want to test my Controller (even if there is no logic in my example) with the following code:

[TestClass]
public class IndexControllerTest
{
    [TestMethod]
    public void IndexActionTest()
    {
        IndexController controller = new IndexController();
        ViewResult view = controller.Index() as ViewResult;
        Assert.IsNotNull(view);
    }
}

I just want to check that the view is not null but the test fails. I get a NullReferenceException because the HttpContext property of the Controller is null. This happens because there is no web context when executing the test and it makes sense since the execution occurred in a test context.

The first thing that comes to mind to fix this issue is to set the HttpContext property with a mock. But I cannot do that because this property is read only and thus I am not able to set it when doing the instantiation of the controller in the test method.

And if you need to mock the HttpContext class, you cannot because it is sealed. To avoid this you can use the HttpContextBase abstract class instead but in a test environment you will have to implement it in order to mock it and you don’t want to do this. Why? Because it’s a pain to do, you will have to provide implementation for everything, it’s like creating an entire web context just for the test. And in my case I just need the user languages.

So? What now? Do we give up testing our controllers? Absolutely not, it is possible to achieve our goal without too much complications. From the beginning I tried to mock the wrong thing. What I need is the user languages not the HttpContext, so let’s remove this dependency. I created the following interface with the data my code will use:

public interface IWebContext
{
    string[] UserLanguages { get; }
}

And now I will inject this interface in my Controller and I will create a specific implementation that will use the HttpContext to retrieve the languages from the request:

public class RealContext : IWebContext
{
    private HttpContext _context;
 
    public RealContext(HttpContext context)
    {
        _context = context;
    }
 
    public string[] UserLanguages
    {
        get { return _context.Request.UserLanguages; }
    }
}
 
public class IndexController : Controller
{
    IWebContext _context;
 
    public IndexController()
        : this(new RealContext(System.Web.HttpContext.Current)) { }
 
    public IndexController(IWebContext context)
    {
        _context = context;
    }
 
    [HttpGet]
    public ActionResult Index()
    {
        string[] languages = _context.UserLanguages;
        return View(model:languages);
    }
}

Note that I created a parameters-less constructor that instantiate the dependency, without this constructor the ASP .NET MVC will not be able to create the Controller (it won’t even compile).

I can now update my test by using a mock for my interface:

public class MockContext : IWebContext
{
    public string[] UserLanguages
    {
        get { return new string[1]; }
    }
}
 
[TestClass]
public class IndexControllerTest
{
    [TestMethod]
    public void IndexActionTest()
    {
        IndexController controller = new IndexController(new MockContext());
        ViewResult view = controller.Index() as ViewResult;
        Assert.IsNotNull(view);
    }
}

My test is now passing! I removed the dependency between the test and the web context objects, I can now test the logic of my controller without having to set up an awful lot of mocks.

I encapsulated my specific logic inside an abstraction that is far easier to mock. This way I was able to reduced the coupling, I was also able to increase my code coverage and all of it without losing any behavior.

You can use this technique for other properties of the HttpContext like the user agent if you want to apply some logic on it and test it. Or also for static classes/methods (that you can maybe found in your legacy code).

I hope this will help you and as usual do not hesitate to leave a comment.

See you next time!

Model validation in ASP .NET MVC

Julien Fiaffé Coding Tips , , , , , ,

form-validation

I worked for several years as an ASP .NET MVC developer and I still do even if I do less front-end development at the moment. During my professional life I came across a few tips for this technology that helped me making my code cleaner and less coupled.

Before creating this blog I owned another one in french where I posted a few articles related to Model validation for a form. I will expose the concept of these articles in this new blog post, in english this time. Maybe it will look obvious for you but I wish I knew these tips when I started working with ASP .NET MVC and this is why I’m creating this blog entry, it might help some of you.

The problem

I created the following form for example, which ask for a name and an IP address:

I created this form using a new empty MVC application in Visual Studio and here is the Index.cshtml view:

@model CodingTips.Web.Models.IPAddressModel
 
<h2>IP Address form</h2>
@using (Html.BeginForm())
{
    @Html.AntiForgeryToken()
    <div>
        @Html.LabelFor(m => Model.Name):
    </div>
    <div>
        @Html.TextBoxFor(m => Model.Name)
        @Html.ValidationMessageFor(m => Model.Name)
    </div>
    <div>
        @Html.LabelFor(m => Model.IPAddress):
    </div>
    <div>
        @Html.TextBoxFor(m => Model.IPAddress)
        @Html.ValidationMessageFor(m => Model.IPAddress)
    </div>
    <input type="submit" />
}

The Model and the Controller are defined the following way at the moment:

public class IPAddressModel
{
    [Required]
    [Display(Name = "Your name")]
    public string Name { get; set; }
 
    [Required]
    [Display(Name = "Your IP address")]
    public string IPAddress { get; set; }
}
 
public class HomeController : Controller
{
    [HttpGet]
    public ActionResult Index()
    {
        return View();
    }
 
    [HttpPost]
    [ValidateAntiForgeryToken]
    public ActionResult Index(IPAddressModel model)
    {
        if (!ModelState.IsValid)
        {
            return View(model);
        }
 
        return RedirectToAction("Validate");
    }
 
    [HttpGet]
    public string Validate()
    {
        return "Your IP address has been registered";
    }
}

As you can see I already put some validation logic that will only verify that the fields are not left empty. If the user fill the two text boxes he will be redirected to a page containing only a confirmation message, this is the final result.

But, as you probably guessed it, there are issues with this validation code, the IP address field can be filled with any string value and the Model will be valid. This is not what we desire, we want a more accurate validation for this field and this is what I will show in this article.

When I began working with ASP .NET MVC my first thought, when I encountered an issue like this one, was to add all the validation logic inside the POST action of the Controller. Well, it can work but this is not the place to do so, this option increase the code coupling especially when the Model to validate is huge. In my opinion the Controller should only take care of the “flow” logic of the application and the validation should be placed somewhere else.

The good news is that ASP .NET MVC has been designed to be extensible for Model validation in an easy way. Let’s see how this can be done.

IValidatableObject

It is possible to add validation at the class-level, directly on the Model itself by implementing a specific interface: IValidatableObject. There is only one method available in this interface, the Validate() method. It will be automatically called by the MVC framework when the ModelState.IsValid code is executed, which is already present in our Controller. Let’s see the new version of the Model:

public class IPAddressModel : IValidatableObject
{
    [Required]
    [Display(Name = "Your name")]
    public string Name { get; set; }
 
    [Required]
    [Display(Name = "Your IP address")]
    public string IPAddress { get; set; }
 
    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        const string regexPattern = @"^([\d]{1,3}\.){3}[\d]{1,3}$";
        var regex = new Regex(regexPattern);
 
        if (!regex.IsMatch(IPAddress))
            yield return new ValidationResult("IP address format is invalid", new[] { "IPAddress" });
    }
}

In this first implementation of the Validate() method I simply check that the given address match an IP V4 format (xxx.xxx.xxx.xxx). I have nothing else to do before being able to test this new behavior in my form.

ip-address-format-error

It works as expected. Yet, the validation is not over since I can put the value 800.800.800.800 (which is not valid for an IP address) without having any error, there is more validation to do:

public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
{
    const string regexPattern = @"^([\d]{1,3}\.){3}[\d]{1,3}$";
    var regex = new Regex(regexPattern);
 
    if (!regex.IsMatch(IPAddress))
        yield return new ValidationResult("IP address format is invalid", new[] { "IPAddress" });
 
    string[] values = IPAddress.Split(new[] { '.' }, StringSplitOptions.RemoveEmptyEntries);
 
    byte ipByteValue;
    foreach (string token in values)
    {
        if (!byte.TryParse(token, out ipByteValue))
            yield return new ValidationResult("IP address value is incorrect", new[] { "IPAddress" });
    }
}

I extended the Validate() method in order to add more logic and to check that each element of the IP address has a correct value. I did this by checking that each of them can be transformed into a byte (value from 0 to 255).

ip-address-value-error

By using the IValidatableObject interface I was able to add validation logic to my Model without modifying my Controller. Doing so can be helpful when you have validation logic that depends on several properties of the Model.

In our example I used this interface only to check a single property and therefore it can look a bit “overpowered”. And if I have another form with a IP address field I will need to extract this part of the logic into a specific method to avoid code duplication. This point leads me to my next tip.

Custom attribute

To add validation to a specific field, the IP address one in our case, my advice will be to create a custom validation attribute. This will allow me to put the validation logic in one place only. Here’s the attribute implementation:

public class IpAddressAttribute : RegularExpressionAttribute
{
    public IpAddressAttribute()
        : base(@"^([\d]{1,3}\.){3}[\d]{1,3}$")
    {}
 
    public override bool IsValid(object value)
    {
        if (!base.IsValid(value))
            return false;
 
        string ipValue = value as string;
        if (IsIpAddressValid(ipValue))
            return true;
 
        return false;
    }
 
    private bool IsIpAddressValid(string ipAddress)
    {
        if (string.IsNullOrEmpty(ipAddress))
            return false;
 
        string[] values = ipAddress.Split(new[] { '.' }, StringSplitOptions.RemoveEmptyEntries);
 
        byte ipByteValue;
        foreach (string token in values)
        {
            if (!byte.TryParse(token, out ipByteValue))
                return false;
        }
 
        return true;
    }
 
    public override string FormatErrorMessage(string name)
    {
        return string.Format("The '{0}' field has an invalid format.", name);
    }
}

The logic is exactly the same as the one present in the IValidatableObject chapter. First checking the overall format with a regular expression and this is why I created a RegularExpressionAttribute subtype. Then the value of each byte is checked. Now I can use this attribute on my Model:

public class IPAddressModel
{
    [Required]
    [Display(Name = "Your name")]
    public string Name { get; set; }
 
    [IpAddress]
    [Required]
    [Display(Name = "Your IP address")]
    public string IPAddress { get; set; }
}

The Controller is unchanged, the Model is much cleaner and I can easily reuse my attribute for each IP address property in my application models without duplicating the logic.

My Model is now fully checked but only on the server-side, and this validation can clearly be done on the client-side as well with some JavaScript. This will avoid unnecessary HTTP requests between the browser and the server.

jQuery validation

ASP .NET now integrates a lot of third-party JavaScript libraries and among them there is jQuery which we will use to achieve client-side validation. I updated the _Layout.cshtml view to add the following lines:

<script src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-2.1.3.min.js"></script>
<script src="http://ajax.aspnetcdn.com/ajax/jquery.validate/1.13.0/jquery.validate.min.js"></script>
<script src="http://ajax.aspnetcdn.com/ajax/mvc/5.1/jquery.validate.unobtrusive.min.js"></script>

You can find different versions of these script here if you need specific ones. You also have to check that the Web.config is configured in order to enable client-side validation with jQuery:

<configuration>
  <appSettings>
    <add key="ClientValidationEnabled" value="true"/>
    <add key="UnobtrusiveJavaScriptEnabled" value="true"/>
  </appSettings>
  ...
</configuration>

I can test the form again and see what is happening.

ip-address-jquery

The data have been checked without posting them to the server. This is possible because the @Html.TextBoxFor() method has generated the following HTML for the IP address field:

<input data-val="true" data-val-required="The Your IP address field is required." id="IPAddress" name="IPAddress" type="text" value="" aria-required="true" class="input-validation-error" aria-describedby="IPAddress-error IPAddress-error" aria-invalid="true">

The data-val-* attributes (HTML5) are used by the jquery.validate plugin to perform the client-side validation. But as you can see, there is nothing related to our regular expression pattern we defined for the IPAddressAttribute. And if you try to validate the form with an invalid IP address the form will still be posted to the server. At the moment the client-site validation is not complete.

IClientValidatable

ASP .NET MVC allow us to extend the generated HTML in order to add more control over the fields in the form. For that I will make the IpAddressAttribute implementing the IClientValidatable interface.

public class IpAddressAttribute : RegularExpressionAttribute, IClientValidatable
{
    public IpAddressAttribute()
        : base(@"^([\d]{1,3}\.){3}[\d]{1,3}$")
    {}
 
    public override bool IsValid(object value)
    {
        // does not change
        ...
    }
 
    private bool IsIpAddressValid(string ipAddress)
    {
        // does not change
        ...
    }
 
    public override string FormatErrorMessage(string name)
    {
        return string.Format("The '{0}' field has an invalid format.", name);
    }
 
    public IEnumerable<ModelClientValidationRule> GetClientValidationRules(ModelMetadata metadata, ControllerContext context)
    {
        string fieldName = metadata.DisplayName;
        string errorMessage = string.Format("The '{0}' field has an invalid format.", fieldName);
        const string pattern = @"^([\d]{1,3}\.){3}[\d]{1,3}$";
 
        ModelClientValidationRegexRule patternRule = new ModelClientValidationRegexRule(errorMessage, pattern);
        yield return patternRule;
 
        ModelClientValidationRule ipRule = new ModelClientValidationRule();
        ipRule.ValidationType = "ipformat";
        ipRule.ErrorMessage = string.Format("The '{0}' field has an invalid value.", fieldName);
 
        yield return ipRule;
    }
}

This method adds two new validation rule for the client-side code. The first one is for the regular expression and I use the existing ModelClientValidationRegexRule class to do so. The second one is a custom ModelClientValidationRule for which I defined the type as “ipformat”. This means that the input in the form will have a data-val-ipformat attribute.

This attribute is not recognized by the jQuery validation plugin, so I created a IPFormat.js file to extend it:

$.validator.unobtrusive.adapters.addBool("ipformat");
 
$.validator.addMethod("ipformat", function (value, element) {
    if (!value) {
        return false;
    }
    var bytes = value.split(".");
    if (bytes.length != 4) {
        return false;
    }
    for (i in bytes) {
        var entry = bytes[i];
        if (!entry) {
            return false;
        }
        var byte = parseInt(entry);
        if (isNaN(byte) || byte < 0 || byte > 255){
            return false;
        }
    }
    return true;
});

After including this file in my _Layout.cshtm view, I can see that the generated HTML for the text box has changed.

<script src="~/Scripts/Validators/IPFormat.js"></script>
<input data-val="true" data-val-ipformat="The 'Your IP address' field has an invalid value." data-val-regex="The 'Your IP address' field has an invalid format." data-val-regex-pattern="^([\d]{1,3}\.){3}[\d]{1,3}$" data-val-required="The Your IP address field is required." id="IPAddress" name="IPAddress" type="text" value="" aria-required="true" aria-invalid="true" class="input-validation-error" aria-describedby="IPAddress-error">

I now have my attributes for the regular expression validation and for the ipformat validation. Let’s try the form once again.

ip-address-jquery-custom

Here we are, the IP address is fully checked without being sent to the server. To achieve this I only used functionalities present in the framework, such as the IValidatableObject interface, the custom validation attributes, the IClientValidatable interface and a bit of jQuery.

This is the end of this blog post about Model validation in ASP .NET MVC on both server-side and client-side. I hope this will help you and as usual do not hesitate to comment and share this.

See you next time!

2014 is over, welcome in 2015

Julien Fiaffé General

happy-new-year-2015Another year is over and it is time for me to wish you a happy new year!

I hope 2014 has treated you well as it did for me. During this year I found a new job that I really enjoy which fits all my current needs.

In 2014 I also met a lot of interesting people through meetups, these were formidable opportunity to discover new technics and ideas and I will continue on this path in 2015.

I also created this new blog to expose my ideas regarding software development and I like writing new articles for it and I hope you like them as well. I had visitors from all around the world and I want to thank you for that, it is very motivating for me. And don’t worry the articles (the technical ones) are coming back shortly.

Once again: Happy New Year 2015 and thank you!

See you next time!