January 28, 2010

Writing your own filters with LINQ

I recently read an article by Mark Needham on how we tend to duplicate LINQ filters in our code.  He makes a good point – for example, you might see the following code in your application.

users.Single(u => u.Id == id)

While this is a pretty simple line of code we might end up duplicating this filter in a number of places.  In his example he uses a simple property to avoid the duplication - I usually write my own filters.

public static class UserFilters
{
    public static User WithId(this IQueryable<User> users, int id)
    {
        return users.Single(u => u.Id == id);
    }
}

The original code now also becomes much more readable.

users.WithId(id)

Another bonus here is that we can write unit tests for our filters!

[Test]
public void ShouldFilterUsersBySpecifiedAge()
{
    SystemTime.Now = () => new DateTime(2020,1,1);

    var users = new List<User>();
    users.Add(new User { Birthdate = new DateTime(2010,1,1) });
    users.Add(new User { Birthdate = new DateTime(2005,1,1) });
    users.Add(new User { Birthdate = new DateTime(2000,1,1) });
    users.Add(new User { Birthdate = new DateTime(1995,1,1) });

    Assert.AreEqual(2, users.AsQueryable().OlderThan(18).Count());
}

Less duplication, improved readability and testability.  This trick is especially useful if you are using complex filters.  If you’re wondering about my use of SystemTime – this is a trick I learnt from Ayende Rahien.

Happy coding.

Implementing a custom LINQ provider

I recently read an interesting article that describes how the LINQ to SQL provider was implemented.  The article gave a pretty good description of expression trees and how they relate to IQueryable and LINQ.  I thought it might be interesting to try and implement my own LINQ provider to gain a better understanding of the LINQ technology.

LINQ to File System

I thought a pretty easy and useful example would be to implement a LINQ provider for the file system – the idea being that you specify a root path and the LINQ provider would allow you to query files and folders within this root path.

There is another very useful walkthrough on MSDN that guides the reader through the different steps for creating a LINQ provider – I used concepts from this article extensively in my implementation.

Implementing IQueryable<T>

The first thing we need to do is to write an implementation for the IQueryable<T> interface.  (In my provider I actually implemented the IOrderedQueryable<T> interface, which inherits from IQueryable<T>)  I also created a FileSystemElement class which is basically a wrapper for any file element we query.  We will see later on that we can apply filters on any property in this FileSystemElement class.

public class FileSystemContext : IOrderedQueryable<FileSystemElement>
{
    public FileSystemContext(string root)
    {
        Provider = new FileSystemProvider(root);
        Expression = Expression.Constant(this);
    }

    internal FileSystemContext(IQueryProvider provider, Expression expression)
    {
        Provider = provider;
        Expression = expression;
    }

    public IEnumerator<FileSystemElement> GetEnumerator()
    {
        return Provider.Execute<IEnumerable<FileSystemElement>>(Expression).GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }

    public Type ElementType
    {
        get { return typeof(FileSystemElement); }
    }

    public Expression Expression { get; private set; }
    public IQueryProvider Provider { get; private set; }
}
public enum ElementType
{
    File,
    Folder
}

public abstract class FileSystemElement
{
    public string Path { get; private set; }
    public abstract ElementType ElementType { get; }

    protected FileSystemElement(string path)
    {
        Path = path;
    }
}

Implementing IQueryProvider

The next step is to implement the IQueryProvider interface – this class is responsible for creating queries and evaluating them.  At the lowest level this basically means we need to be able to create queries and then execute them. 

public class FileSystemProvider : IQueryProvider
{
    private readonly string root;

    public FileSystemProvider(string root)
    {
        this.root = root;
    }

    public IQueryable CreateQuery(Expression expression)
    {
        return new FileSystemContext(this, expression);
    }

    public IQueryable<TElement> CreateQuery<TElement>(Expression expression)
    {
        return (IQueryable<TElement>) new FileSystemContext(this, expression);
    }

    public object Execute(Expression expression)
    {
        return Execute<FileSystemElement>(expression);
    }

    public TResult Execute<TResult>(Expression expression)
    {
        var isEnumerable = (typeof(TResult).Name == "IEnumerable`1");
        return (TResult) FileSystemQueryContext.Execute(expression, isEnumerable, root);
    }
}

So far we haven’t done any real magic – we’re basically using the expression tree created by the compiler and delegating the evaluation of expressions to the FileSystemQueryContext class.

Evaluating expressions

Keep in mind that I don’t really want to manually evaluate expressions – I simply want to retrieve all files and folders from the file system and allow the user to filter on the FileSystemElement class I’m returning.  The only real work I want to do is to retrieve the files and folders and wrap them in an IQueryable<FileSystemElement> interface. 

I also need to copy the expression tree that represents the LINQ query and make a single modification – we simply replace the data source with the concrete list of files and folders.

Luckily the walkthrough on MSDN already provides an implementation of an ExpressionVisitor class – this class basically does all the work for us.

public class FileSystemQueryContext
{
    internal static object Execute(Expression expression, bool isEnumerable, string root)
    {
        var queryableElements = GetAllFilesAndFolders(root);

        // Copy the expression tree that was passed in, changing only the first
        // argument of the innermost MethodCallExpression.
        var treeCopier = new ExpressionTreeModifier(queryableElements);
        var newExpressionTree = treeCopier.CopyAndModify(expression);

        // This step creates an IQueryable that executes by replacing Queryable methods with Enumerable methods.
        if (isEnumerable)
        {
            return queryableElements.Provider.CreateQuery(newExpressionTree);
        }
        else
        {
            return queryableElements.Provider.Execute(newExpressionTree);
        }
    }

    private static IQueryable<FileSystemElement> GetAllFilesAndFolders(string root)
    {
        var list = new List<FileSystemElement>();
        foreach (var directory in Directory.GetDirectories(root))
        {
            list.Add(new FolderElement(directory));
        }
        foreach (var file in Directory.GetFiles(root))
        {
            list.Add(new FileElement(file));
        }
        return list.AsQueryable();
    }
}

Here is the method where I look for a call to the FileSystemContext class – which I replace with the list of files and folders.

protected override Expression VisitConstant(ConstantExpression c)
{
    // Replace the constant FileSystemContext arg with the queryable fileSystemElements.
    if (c.Type == typeof(FileSystemContext))
    {
        return Expression.Constant(fileSystemElements);
    }
    else
    {
        return c;
    }
}

Using the new provider

The following is an example of kind of query we can write with this provider.

var query = from element in new FileSystemContext(@"C:\Downloads") 
            where element.ElementType == ElementType.File && element.Path.EndsWith(".zip")
            orderby element.Path ascending 
            select element;

Which is actually quite cool.  When I started this exercise I thought that it would actually be a lot more work – granted, I’m delegating most of the work to the underlying technology, but still – it was easier than I thought.

By the way, keep in mind I wrote this provider as an example – you would be absolutely nuts to actually write a LINQ provider for this kind of file access.  The following code does pretty much the same as my implementation, minus any of the hard work.

var files = from file in new DirectoryInfo(@"C:\Downloads").GetFiles()
            where file.Extension == "zip"
            select file;

You can download the code here.  Happy coding.

January 27, 2010

Permission-based access in ASP.NET MVC

I recently read an interesting blog about implementing Role-based access in MVC using custom attributes.  I have implemented a similar strategy for Permission-based access by using the session object.

Storing the permissions

I usually define a user’s permissions as an enumeration and then simply store this as an integer in the database.  You might need permissions to be defined at a group or role-level, but in most cases this will do what is required.  YAGNI!

[Flags]
public enum Permissions
{
    View                 = (1 << 0),
    Add                  = (1 << 1),
    Edit                 = (1 << 2),
    Delete               = (1 << 3),
    Admin                = (View | Add | Edit | Delete)
}

This is the set of permissions I’m going to use for specifying access rights on my actions.

Store the user object in the session

We’re going to need access to the current user’s permissions if we want to determine if the current user has the necessary permissions to perform a certain action.  I find the easiest thing to do is to simply store the current user in the session.  I’ve had some lively debates around this – the best argument against this being that any changes to the user object will cause all users to lose their sessions.  While this is a valid argument, I prefer doing the simplest thing that could possibly work.  YAGNI!

public ActionResult Authenticate(string username, string password)
{
    var user = authenticationService.Authenticate(username, password);
    Session["User"] = user;
                
    return RedirectToAction("Somewhere", "Else");   
}

Create a custom attribute for authorizing access

The last step is to create a custom attribute for authorizing access to our actions.

public class PermissionsAttribute : ActionFilterAttribute
{
    private readonly Permissions required;

    public PermissionsAttribute(Permissions required)
    {
        this.required = required;
    }

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        var user = filterContext.HttpContext.Session.GetUser();
        if (user == null)
        {
            //send them off to the login page
            var url = new UrlHelper(filterContext.RequestContext);
            var loginUrl = url.Content("~/Home/Login"); 
            filterContext.HttpContext.Response.Redirect(loginUrl, true);    
        }
        else
        {
            if (!user.HasPermissions(required))
            {
                throw new AuthenticationException("You do not have the necessary permission to perform this action");
            }
        }
    }
}

And that’s all we need.  Now we can specify the necessary permissions on each controller action.

[Permissions(Permissions.View)]
public ActionResult Index()
{
    // ...
}

Happy coding.

January 21, 2010

How to use View Models

I’ve had quite a few discussions around view models and the different patterns around using them in MVC.  A while back I read an interesting article by Steve Michelotti about the subject and I would like to expand on his arguments.

He argues that there are 3 different models for constructing view models – I would like to argue that there are 3 different ways we can use view models in our applications.

Using your domain model for displaying and posting data

The first way of using view models is to use your domain model as your view model.  You will pass your domain model to your views directly for displaying data and the view will post domain objects to the controller directly.

public ActionResult Index()
{
    return View("Index", service.GetContacts());
}

public ActionResult Add(Contact contact)
{
    service.Add(contact);

    return RedirectToAction("Index");
}

This approach is very easy to implement and straightforward.  There is no mapping between view models and domain models and code is clean and concise.

Unfortunately there are a couple of drawbacks with using this approach.  The first is that there is often a mismatch between what the domain model contains and what we want to display.  The domain model often contains more data than the view actually requires – not a massive issue, but worth noting.  The second issue is that we often deal with multiple domain objects and once in our views.  This becomes particularly annoying when trying to post data that belongs to more than one domain object – the controllers tend to do too much and the code becomes cluttered and difficult to test or maintain.

Using the view model for displaying and posting data

The second approach is to always use view models inside our views.  When displaying data we will perform the mapping from the domain model to the view model and when posting data we will map from the view model back to the domain model.

public ActionResult Index()
{
    var widgets = service.GetWidgets();

    var list = new List<WidgetViewModel>();
    foreach (var widget in widgets)
    {
        list.Add(new WidgetViewModel { Color = widget.Color, Size = widget.Size, Texture = widget.Texture });
    }

    return View("Index", list);
}

public ActionResult Add(WidgetViewModel viewModel)
{
    var widget = new Widget();

    widget.Color = viewModel.Color;
    widget.Size = viewModel.Size;
    widget.Texture = viewModel.Texture;

    service.Add(widget);

    return RedirectToAction("Index");
}

This approach has more overhead than the first option, but is much more flexible.  In this example the mapping code is very tedious, but I find more often than not I require the flexibility available with the view model, especially when adding or updating.

The obvious drawback here is the added mapping code and the need to create a separate view model object – less code is better.

Using the domain model for displaying and view model for posting data

The third approach (which is the one I prefer) is a hybrid approach – use the domain model for displaying data and the view model for adding or updating.  The means that we will always pass domain objects to the views and the views will always pass view model objects to the controllers.

public ActionResult Index()
{
    return View("Index", service.GetUsers());
}

public ActionResult Add(UserViewModel viewModel)
{
    var user = new User();

    user.Name = viewModel.Name;
    user.Surname = viewModel.Surname;
    user.IdNumber = viewModel.IdNumber;

    service.Add(user);

    return RedirectToAction("Index");
}

I feel this approach has the least amount of overhead in terms of mapping between the domain model and view model while maintaining all the necessary flexibility.  I find that simply using a subset of the domain model when displaying data is pretty straightforward and most of my issues arise when trying to post data back to the server – hence the use of the view model.

Summary

I think it’s very important to choose the approach that works for you and consistently use it throughout your application.  Keep in mind that each approach has advantages and disadvantages and choose one that works for you.

Also keep in mind that AutoMapper can alleviate much of the pain around the mapping between domain and view models.  I haven’t written an MVC application using view models for displaying and posting data with AutoMapper performing all the mapping, but it definitely seems like a very cool approach.

Happy coding.

January 20, 2010

Use View Models instead of FormCollection

I have recently been spending quite a bit of time on StackOverflow and I noticed that quite a few of the MVC-related answers make use of the FormCollection class.  If you’re unfamiliar with this class, here is an example of how it gets used:

<% using (Html.BeginForm("Add", "Contacts", FormMethod.Post)) { %>
    
    <label for="Name">Name:</label><input type="text" name="Name" /><br />
    <label for="Surname">Surname:</label><input type="text" name="Surname" /><br />
    <label for="CellNumber">Cellphone Number:</label><input type="text" name="CellNumber" /><br />
    
    <input type="submit" value="Add" />
    
<% } %>    
public ActionResult Add(FormCollection formValues)
{
    var contact = new Contact();

    contact.Name = formValues["Name"];
    contact.Surname = formValues["Surname"];
    contact.CellNumber = formValues["CellNumber"];

    service.Add(contact);

    return RedirectToAction("Index");
}

Which of course works exactly as expected.  Let’s take a look at the same example using a view model.

public class ContactViewModel
{
    public string Name { get; set; }
    public string Surname { get; set; }
    public string CellNumber { get; set; }
}
public ActionResult Add(ContactViewModel viewModel)
{
    var contact = new Contact();

    contact.Name = viewModel.Name;
    contact.Surname = viewModel.Surname;
    contact.CellNumber = viewModel.CellNumber;

    service.Add(contact);

    return RedirectToAction("Index");
}

Which I think is a lot neater (plus no magic strings).  I find that this approach is much easier to test and maintain.

Keep in mind that you can even create your own model binder for specifying how the form values should bind to the view model.  (More on this in a later post).  However in most cases the default model binder should be sufficient.

Happy coding.

January 12, 2010

Why I like Pair Programming

Pair programming is easily the most controversial agile development practice and in my experience the most frequently avoided.  It makes some people pretty uncomfortable.

pairon

Pair programming means two developers working together on one computer.  It promotes working very closely with your fellow developers and forces you to learn from your colleagues.  It helps to decrease or eliminate key person dependency and promotes unified naming conventions and code structures.  So why don’t we like it?

Why the negativity?

Let’s face facts – most software developers shun the idea of pair programming.  The basic concept of working with someone looking over your shoulder or (even worse) having to look over someone else’s shoulder while they’re working doesn’t really sound appealing.  You also have to deal with one of your colleagues invading your personal space – not a very pleasant thought.

I guess at the end of the day we all want to be rock-star developers: music on, eyes glued to the monitor, fingers moving across the keyboard at lightning speed…  Unfortunately this is not the picture of a productive developer.  Programming is not about creating software as fast as possible – it’s about creating bug-free, testable, consistent, maintainable software that will outlast us all while being flexible enough to meet changing business needs.  The rock-star developer simply doesn’t fit into this mould.

The problem is that the rock-star doesn’t communicate with his fellow developers.  He doesn’t follow coding standards.  He doesn’t write automated tests.  He doesn’t care about your naming conventions and he sure as hell doesn’t care about re-using your code.  Pair programming prevents you from being a rock-star developer – and that’s a good thing.

Resist the rock-star developer!

Once you get used to the idea of constantly engaging with a fellow developer it can actually be pretty fun.  You’ll be learning new concepts and patterns.  You’ll be bouncing ideas around all the time.  If you need to talk through a problematic piece of code - there is someone sitting right next to you!

I especially like pair programming because it forces me to be productive while at my desk.  Let’s face it – we’re al human.  After banging away at the keyboard for a few hours you are going to lose concentration – check you email, read the news, chat on msn – you need to do something to let your fingers and mind rest.  When I’m pair programming I find this isn’t really an issue – if you find yourself getting tired simply stop typing and hand the keyboard to your pair.  I find this switch allows me to stay productive for pretty much the whole day.

It’s still a difficult sell

It’s still difficult to convince your fellow developers and managers that pair programming is the way to go.  Initially you won’t be as productive as before – pair programming, as everything in software development, takes some experience to really get the most out of it.  Plus you will need to convince your management that it will now take 2 developers to do the work that one usually did.

But don’t be discouraged.  The long-term benefits of pair programming are incredible.  Your team will produce consistent code with less bugs in a shorter space of time while increasing the technical skills of all the developers.  You will probably get a lot of resistance (from developers and management alike).  Don’t despair - keep at it – once they see the benefits, developers and management alike will come to the party.

The benefits of pair programming are simply too great for us not to be doing it.  Happy coding.

January 7, 2010

Multithreading example in C#

There is a certain pattern I tend to lean on when performing multithreading operations.  C# exposes some very useful functionality for dealing with multithreading problems – in this example I’m going to take a look at the ThreadPool class.

For this example I’m going to calculate Fibonacci numbers – this is an easy example since the numbers can be calculated in parallel and the order in which we calculate the numbers are unimportant.

ThreadPool

The ThreadPool class allows us to delegate the use of multiple threads to the .NET framework.  This means that the .NET framework will decide how many threads should be used to perform the specified operation and how threads should be re-used.  If we didn’t have this functionality we would have to manually decide when to create and re-use threads.  As we will see in the example the .NET framework does this in an optimal way.

To request that a work item be handled by a thread in the thread pool we call the QueueUserWorkItem method, which accepts a delegate.  Since we want each delegate/method to execute in a specific context I usually create a separate class and then create an instance of the class for each multithreaded operation.  In this example I created a class called ‘Worker’ with a delegate called ‘Calculate’.

public class Worker
{
    private readonly int nthNumber;

    public Worker(int nthNumber)
    {
        this.nthNumber = nthNumber;
    }

    public void Calculate(object o)
    {
        Console.WriteLine("Fibonacci {0} is {1}", nthNumber, Fibonacci(nthNumber));
    }

    internal static int Fibonacci(int n)
    {
        if (n == 0)
        {
            return 0;
        }
        else if (n == 1)
        {
            return 1;
        }
        else
        {
            return Fibonacci(n - 1) + Fibonacci(n - 2);
        }
    }
}

That’s the first step.  Now we need to be able to tell when all the threads have completed.  The main thread in our application will need to block and wait for all operations to complete.

Thread synchronization

One way of implementing this functionality would be to save all the results to a list and have the main thread check the results every second to see if all the results have been calculated.  This is obviously not the ideal situation since we will be wasting a massive amount of resources by running this check and we would also need to synchronize access to the results list.

Luckily for us C# exposes a number of thread synchronization techniques.  The one I’m using in this example is the EventWaitHandle class.  The analogy I use for explaining this structure is that of a turnstile – you have to wait at the turnstile until someone else allows you to pass through.  In this case the main application thread will wait until all the threads have completed – the last thread to complete simply needs to signal the turnstile or EventWaitHandle.

Now we have the final problem – a thread needs to know that it is the last thread to complete.  To do this I simply declare a static counter inside my worker class – I increment the variable every time a worker is created and decrement the variable every time the worker completes.  The only trick is that we need to increment and decrement the counter as an atomic operation – we can do this by using the Interlocked.Increment and Interlocked.Decrement methods.

internal static readonly EventWaitHandle AllWorkersCompleted = new EventWaitHandle(false, EventResetMode.AutoReset);
private static int numberOfWorkers = 0;
private readonly int nthNumber;

public Worker(int nthNumber)
{
    Interlocked.Increment(ref numberOfWorkers);
    this.nthNumber = nthNumber;
}

public void Calculate(object o)
{
    Console.WriteLine("Fibonacci {0} is {1}", nthNumber, Fibonacci(nthNumber));
    if (Interlocked.Decrement(ref numberOfWorkers) == 0)
    {
        AllWorkersCompleted.Set();
    }
}

Now we simply need create a worker instance for each number we want to calculate and use the ThreadPool class to schedule each calculation.

Performance

To test the performance of my application I calculated the first 44 Fibonacci numbers – first using a single thread and then in parallel.  On my laptop (Intel Core Duo 2.2 GHz with 4GB RAM) the single-threaded calculations complete in about 80 seconds and the multi-threaded calculations in about 50 seconds.

The really cool part (in my opinion) is taking a look at task manager while executing the multi-threaded operations.

Task Manager CPU

No matter how many CPU’s you have the ThreadPool will manage to completely max out CPU usage until the operation completes.  Pretty cool.

You can download the code here.  Happy coding.

January 6, 2010

Debugging JavaScript errors

I have noticed that quite a few developers are unaware of one of the simplest methods of finding JavaScript errors in your page.  JavaScript exposes an event handler that fires whenever a JavaScript error occurs in a page.  Using it we can suppress all JavaScript errors on the page or display an error dialog.

Example

Here is an example of using the onerror event:

<script type="text/javascript">
    window.onerror = function(msg, url, line) {
        alert("JavaScript error: " + msg + " on line " + line);
    }
</script>

Now if we make an obvious error like the following…

<script type="text/javascript">
    document.write("this should produce an error"
</script>

we’ll get a nice detailed error message.

Dialog

This works in Firefox 3 and IE 7.  For some reason this doesn’t work in Chrome (v2.0.172.37).  If you can shed some light on why this doesn’t work in Chrome please do so in the comments section below.

Keep in mind that you shouldn’t deploy this type of error handling into a production server – you might think about using a compiler directive so that the code only exists in Debug mode.

Happy coding.

January 5, 2010

Put JavaScript includes at the bottom of your page

I was reading the jQuery Cookbook yesterday to try and sharpen my JavaScript skills.  Within the first chapter the book highlights something which I’ve never given much attention to – where in your page to include your JavaScript files.  Here is an excerpt.

… modern optimization techniques have declared that pages load faster when the JavaScript is loaded by the browser at the end of a page parse. In other words, if you put JavaScript code at the bottom of a web page, then the browser will load everything in front of it before it loads the JavaScript. This is a good thing because most browsers will typically stop processing other loading initiatives until the JavaScript engine has compiled the JavaScript contained in a web page. It’s sort of a bottleneck in a sense that you have JavaScript at the top of a web page document.

So it’s basically a performance enhancement – your pages will load quicker due to your JavaScript includes being at the bottom of your page (just before the closing <body> element).

There’s another reason why it’s a good idea to do your JavaScript includes at the bottom of your page.  I usually attach all my event handlers and initial function execution inside a ready() function, for example:

$(document).ready(function() {
    alert("Go for it the DOM is loaded");
});

If we simply do all JavaScript includes at the bottom of the page this is no longer necessary – the DOM will be loaded by the time our JavaScript is executed.  This means we can do away with the ready() function – less code is better.  Small beans perhaps, but every little bit helps.

I realize that for some situations it’s easier to place JavaScript in the <head> element, but I can’t really think of a scenario where this is absolutely required.  I actually think the ASP.NET MVC team should think about changing the default project templates to do the JavaScript includes at the bottom of the page, rather than in the <head> element.

Happy coding.