Code Capers

Getting Started With The Arduino

Tue, 31 Jan 2012 09:21:00 -0200

As an engineer, I constantly feel the need to learn new things in order to keep the "saw sharp". Since I write code for a living, I often feel dissatisfied by the notion that everything I create is "virtual". The only way to interact with the things that I create are with a keyboard and mouse. The thought of this often makes me wonder if I would have been happier in a profession where I built things with my hands. People tend to appreciate things more that they can hold and physically interact with. So naturally, this led me to the idea of "How can I make software take on a more physical presence?". Of course I immediately thought of robotics, so I typed the term "robotics" into Google and I discovered the term "Physical Computing". According to Wikipedia, the definition of physical computing is:

Physical computing, in the broadest sense, means building interactive physical systems by the use of software and hardware that can sense and respond to the analog world. While this definition is broad enough to encompass things such as smart automotive traffic control systems or factory automation processes, it is not commonly used to describe them. In the broad sense, physical computing is a creative framework for understanding human beings' relationship to the digital world. In practical use, the term most often describes handmade art, design or DIY hobby projects that use sensors and microcontrollers to translate analog input to a software system, and/or control electro-mechanical devices such as motors, servos, lighting or other hardware.

Immediately after reading about physical computing I was intrigued by the idea so I decided to learn more about the different kinds of microcontroller that are available on the market. Of course, since I am a .NET Developer I already knew about the Netduino. The Netduino is a microcontroller that runs the .NET micro framework and you can use Visual Studio to create sketches. Although this sounded cool I decided that 40+ hours a week in Visual Studio is more than enough for me. Therefore, I opted to go with the Arduino platform instead. The Arduino programming language is a implementation of Wiring, a physical computing platform, which is based on the Processing multimedia programming environment. With the combination of some basic electronics skills and the Arduino you can create almost anything. If you search online you will find all kinds of Arduino based projects which include clocks, weather stations, robots and even 3d printers! To make a long story short I ended up ordering the SparkFun inventor's kit. The kit includes an Arduino Uno R3, some basic components and a step-by-step guide on how to use each one. If you are starting from scratch like me and you have no prior experience with electronics then I strongly recommend buying a kit. The manual that comes with the SparkFun Kit is very well done and of course there are a large community of Arduino developers willing to help if you get stuck.

After you make it through all the tutorials in the kit you will probably lay awake at night just thinking of the possibilities. In addition, you will probably drop some cash because on a bigger breadboard, a multimeter and a soldering station. Anyways, just to whet your appetite here are some examples of things that you can do with an Arduino:

RGB LEDs controlled by an Arduino and sequenced with Flash.

Arduino Robot using a Adafruit motor shield, 2x Sharp IR sensors, one PING sensor and an XPAL XP8000 battery.

And finally, a 3D Printer from MakerBot. Yes, I said 3D Printer! Apparently, this uses a Arduino MEGA under the covers.

In the upcoming months you can expect to see some Arduino and electronics based articles appearing on my blog. Perhaps even an article about how I built my first robot!

Getting Assembly Information Using Reflection

Tue, 03 Jan 2012 17:37:47 -0200

I recently took over a WPF application that needed a little bit of refactoring. One of the places that had a lot of repeated code was the about screen. By using reflection a bunch of properties were being created to display things like the assembly title, version, description and etcetera. The original code looked like this:

public string AssemblyDescription
{
    get
    {
        object[] attributes = Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(AssemblyDescriptionAttribute), false);
        if (attributes.Length == 0)
        {
            return "";
        }
        return ((AssemblyDescriptionAttribute)attributes[0]).Description;
    }
}

public string AssemblyProduct
{
    get
    {
        object[] attributes = Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(AssemblyProductAttribute), false);
        if (attributes.Length == 0)
        {
            return "";
        }
        return ((AssemblyProductAttribute)attributes[0]).Product;
    }
}

You may have noticed that this code does not follow the DRY principle. In case you arent familiar with the term, DRY stands for Don't repeat yourself. In otherwords, if you repeat the same code multiple times then you should try to refactor it into a more generic method.

After analyzing the code you may notice that both of the property getters do the same thing. First, it gets a handle to the current assembly. Next, the GetCustomAttributes method is called to get an object array which contains all the attribute values for a given type. Finally, a little bit of conditional logic is used to emit a value. Using the power of generics and some reflection we can easily build an extension method that will eliminate the redundant code.

Warning: If you are not familiar with generics, reflection and lambda statements then the following code may cause your brain to explode

public static TAttribute[] GetAttributes<TAttribute>(this Assembly assembly) where TAttribute : Attribute {
    return assembly.GetCustomAttributes(typeof(TAttribute), false) as TAttribute[];
}

public static object GetFirstAttributeValue<TAttribute>(
    this Assembly assembly,
    Expression<Func<TAttribute, object>> propertyLambda) where TAttribute : Attribute {
    Type type = typeof(TAttribute);

    var attributeValues = assembly.GetAttributes<TAttribute>();
    if (attributeValues.Length == 0)
        throw new ArgumentException("No values found");

    var member = propertyLambda.Body as MemberExpression;
    if (member == null)
        throw new ArgumentException(string.Format("Expression '{0}' refers to a method, not a property.", propertyLambda));

    var propInfo = member.Member as PropertyInfo;
    if (propInfo == null)
        throw new ArgumentException(string.Format("Expression '{0}' refers to a field, not a property.", propertyLambda));

    if (type != propInfo.ReflectedType && !type.IsSubclassOf(propInfo.ReflectedType))
        throw new ArgumentException(string.Format("Expresion '{0}' refers to a property that is not from type {1}.", propertyLambda, type));

    var firstValue = attributeValues[0];
    return propInfo.GetValue(firstValue, null);
}

The code above basically takes the lambda statement, makes sure its a property expression and then uses reflection to get the value of the object. By the way, I do not take credit for writing the reflection code, most of it was borrowed from this stackoverflow post. In any case, with the help of the extension method above we can now simplify our code as:

private Assembly Assembly { get; set; }

public AboutViewModel()
{
    Assembly = Assembly.GetExecutingAssembly();
}

public string AssemblyDescription {
    get {
        return Assembly.GetFirstAttributeValue<AssemblyDescriptionAttribute>(x => x.Description).ToString();
    }
}

public string AssemblyProduct {
    get {
        return Assembly.GetFirstAttributeValue<AssemblyProductAttribute>(x => x.Product).ToString();
    }
}

As you can see, the code is much cleaner. Also take notice that I cached the call to Assembly.GetExecutingAssembly() in a private variable. This helps with performance and also cleans up the code a little.

Happy Coding!

Using Ninject with MVVM Light

Sun, 06 Nov 2011 03:06:18 -0200

I recently changed jobs and as a result I find myself trying to draw parallels between the ASP.NET MVC development I used to do and the WPF MVVM projects that I am working on now. After spending a couple of weeks reading about WPF and learning the fundamentals I finally sat down to write my first WPF application. I chose MVVM Light as my framework because I felt it had a short learning curve and it was fairly lightweight when compared to some of the other frameworks that are out there.

As a MVC developer, one of my favorite NuGet packages has always been Ninject. Adding Ninject to an MVC application is extremely simple because there is a MVC specific implementation called Ninject.MVC which takes care of all the bootstrapping for you. Once you add the package to your MVC project you simply setup your bindings and your up and running. However, I found myself a little bit confused when I added Ninject to my MVVM Light application. I wasn’t sure how to bootstrap Ninject into the application and since there is no WPF specific version of Ninject I knew I had to do the work myself. However, after a little bit of research I came up with the following solution.

Step 1. Create your Ninject Modules

The NinjectModule class is the easiest way to get your bindings registered. You may have noticed that I have two different modules defined. A “Design Time” module and a “Run Time” module. The DesignTimeContext is a mock database. This allows me to avoid the need to access a real database for design time binding and I also use it for unit testing purposes.

public class DesignTimeModule : NinjectModule {
    public override void Load() {
        Bind<IUnitOfWork>().To<DesignTimeContext>();
    }
}

public class RunTimeModule : NinjectModule {
    public override void Load()
    {
        Bind<IUnitOfWork>().To<MyContext>();
    }
}

Step 2. Wire up the ViewModelLocator

The ViewModelLocator that comes with MVVM Light has a property called IsInDesignModeStatic which you can use to check if you are in design mode or not. We can use this property to figure out if we should utilize the DesignTimeModule or the RunTimeModule that we created in the previous step.

public ViewModelLocator()
{
    if (ViewModelBase.IsInDesignModeStatic)
        _kernel = new StandardKernel(new DesignTimeModule());
    else
        _kernel = new StandardKernel(new RunTimeModule());

    About = _kernel.Get<AboutViewModel>();
    Main = _kernel.Get<MainViewModel>();
}

In my project, I have a ViewModel called ProjectListViewModel and the constructor takes an IUnitOfWork as it’s only parameter:

public ProjectListViewModel( IUnitOfWork unitOfWork )

In order to use this new ViewModel I need to add a property to my ViewModelLocator. As you can see below, I use the Ninject kernel to instantiate a new instance of the ProjectListViewModel. Ninject will also take care of creating a concrete IUnitOfWork implementation and inject it into the constructor based on the bindings we established earlier.

public ProjectListViewModel ProjectList {
    get { return _kernel.Get<ProjectListViewModel>(); }
}

Finally, in the ProjectList View I use the global instance of the ViewModelLocator to assign the ViewModel to the DataContext property.

<Window x:Class="MyProject.View.ProjectList"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
        Title="Projects" 
        Height="450" 
        Width="650"
        DataContext="{Binding ProjectList, Source={StaticResource Locator}}">

I must admit that having a mock database for design time is great because you can pre-populate your repositories with different kinds of data and get immediate feedback on how it works with your UI design. It also gives you the ability to see your databindings at work from within Visual Studio or Blend.

Adding Export Capabilities to the Razor WebGrid

Sat, 03 Sep 2011 03:22:00 -0200

When MVC first came out I really missed having a native grid control. Now a few years later, we have grid support again! In case, you didn’t know the Razor WebGrid was included in the System.Web.Helpers assembly which shipped with ASP.NET MVC 3. Over the years, I have sampled a variety of grid controls such as jqGrid, the Infragistics grid control and the MvcContrib grid. Each grid control has its benefits and disadvantages but I think the new WebGrid offers a clean API which makes development tasks simple. Here is a screenshot of what the grid looks like:

To display a grid on a razor view page, you basically create a new grid object, assign some properties and then call the GetHtml helper method. Here is an example:

@{
    var grid = new WebGrid(canPage: true, canSort: true, rowsPerPage: Model.PagingInfo.PageSize, ajaxUpdateContainerId: "grid");
    grid.Bind(Model.Data, rowCount: Model.PagingInfo.TotalItems, autoSortAndPage: false);       
}

@grid.GetHtml(
    columns: new List<WebGridColumn>() {            
        grid.Column(columnName: "Id", header: "#" ),
        grid.Column(columnName: "Date", header: "Date"),
        grid.Column(columnName: "UniqueId", header: "Unique Id" ),
        grid.Column(columnName: "Text", header: "Random Text" )
    })

Of course, displaying a simple table on a web page is never enough for my demanding clients. I needed to add some additional functionality to my grid, In particular I needed to add some exporting options to my grid. To get started I built out an export to CSV feature. By Utilizing the adapter pattern (a fancy way of saying I wrapped the method call) I was easily able to add in my custom html above the grid which has an export link. Here is my GetHtmlEx method:

public static IHtmlString GetHtmlEx( 
    this WebGrid grid,

    < a long list of parameters >
    string recordsText = RecordsText, 
    string pageText = PageText,
    string exportText = ExportText)
{
    var sb = new StringBuilder();
    sb.Append(grid.GetExportHtml());
    sb.Append(grid.GetHtml(tableStyle, headerStyle, footerStyle, rowStyle, alternatingRowStyle, selectedRowStyle,
                        caption, displayHeader, fillEmptyRows, emptyRowCellValue, columns, exclusions, mode, 
                        firstText, previousText, nextText, lastText, numericLinksCount, htmlAttributes));
    sb.Append(grid.GetTotalsHtml());
    return MvcHtmlString.Create(sb.ToString());
}

Nothing too complicated here, just concatenating some HTML together and returning it as one big MvcHtmlString. The GetExportHtml method prints out the links for exporting to CSV. Since my method wraps the native GetHtml method, I just need to modify the view page and add an ‘Ex’ to the end of the @grid.GetHtml method.

@grid.GetHtmlEx(..)

With the help of my wrapper above, my grid now has some new schizzle:

The code that actually exports the data to a CSV file is tucked away in my view model. However, In order to make my design modular and reusable, I created a base class called WebGridViewModel:

public abstract class WebGridViewModel<T>
{
    private IQueryable<T> _superset;        

    protected WebGridViewModel(WebGridSettings settings)
    {
        Settings = settings;                        
    }            
    
    public WebGridSettings Settings { get; set; }        

    public IPagination PagingInfo { 
        get { return Data as IPagination; } 
    }        

    protected abstract IQueryable<T> GetSuperSet();

    protected virtual IEnumerable<object> GetExportData()
    {
        return GetSuperSet() as IEnumerable<object>;
    }

    public ActionResult View( Controller controller, string viewName = "" )
    {
        var shouldExport = !String.IsNullOrWhiteSpace(Settings.ExportTo);            
        if( shouldExport ) return GetExportViewResult();

        controller.ViewData.Model = this;
        var viewResult = new ViewResult() {ViewData = controller.ViewData };

        if (!String.IsNullOrWhiteSpace(viewName))
            viewResult.ViewName = viewName;

        return viewResult;
    }

    private ActionResult GetExportViewResult()
    {
        var name = typeof(T).Name;
        return new CsvActionResult(name + ".csv", GetExportData().ToList());        
    }

    public IEnumerable<T> Data
    {
        get
        {
            if (_superset == null)
                _superset = GetSuperSet();
            
            var sortColumn = String.IsNullOrWhiteSpace(Settings.Sort) ? Settings.DefaultSort : Settings.Sort;
            var sort = String.Format("{0}{1}", sortColumn, String.IsNullOrWhiteSpace(Settings.SortDir) ? "" : " " + Settings.SortDir);
            var ordered = _superset.OrderBy(sort);                
            return ordered.AsPagination(Settings.Page ?? 1, Settings.PageSize);
        }
    }
}

So In order to build the model for my view, the only thing I have to do is inherit from WebGridViewModel and override the GetSuperSet method. I can optionally return a custom result set for the export by overriding the GetExportData method:

public class MyGridViewModel : WebGridViewModel<FakeData>
{
    public MyGridViewModel( WebGridSettings gridSettings )
        : base( gridSettings )
    {
        gridSettings.DefaultSort = "Id";            
    }

    protected override IQueryable<FakeData> GetSuperSet()
    {
        return FakeData.Records;
    }
}

In real life, the GetSuperSet method would hit a database and return some records. However, in order to keep things simple I am using some static data. The Index action of my Home controller takes care of creating the view model and passes it along to the View. Before I added the export feature, my controller action looked like this:

public ActionResult Index( WebGridSettings gridSettings )
{
    var model = new MyGridViewModel(gridSettings);
    return View(model);
}

However, now that my grid supports exporting, I need to support two different action results. A standard ViewResult for displaying the grid on the view page and a custom ActionResult which takes care of building the CSV file and returning it to the client via the response stream. If you look at the implementation details of the WebGridViewModel you may have noticed a method called “View” which basically detects whether or not an export was requested and conditionally returns a regular ViewResult or a CsvActionResult. So the only thing I need to change in the Index method is the return statement:

public ActionResult Index( WebGridSettings gridSettings )
{
    var model = new MyGridViewModel(gridSettings);
    return model.View(this);
}

So now when the Home/Index action is called a standard view is returned. However, when you click on the export hyperlink link an additional query string parameters is added to the url named ExportTo with a value of CSV (Home/Index?ExportTo=CSV). The WebGridViewModel inspects the ExportTo parameter and will automatically determine if a CSV file should be returned.

Download The Sample Code (468.61 kb)

Building MVC Select Lists The Easy Way

Mon, 18 Jul 2011 00:01:00 -0200

It is common to have a view model that contains a list of select list items ( IEnumerable ). However, I get a little annoyed when I see a select list item getting initialized like this:

Widgets = db.Widgets.FindAll().Select(x => new SelectListItem() { Text = x.Name, Value = x.Value });

Although this is legal syntax its just a little bit too ugly for my liking. In an effort to make life simpler I came up with the following helper class:

public static class SelectListFactory
{
    public static IEnumerable<SelectListItem> BuildList<T>(IEnumerable<T> items, Func<T, SelectListItem> func)
    {
        return items.Select(func);
    }        

    public static IEnumerable<SelectListItem> BuildList<T>(
        IEnumerable<T> items,
        Func<T, string> text,
        Func<T, string> value = null,
        Func<T, Boolean> selected = null)
    {
        return items.Select(x => new SelectListItem{
            Text = text.Invoke(x),
            Value = value == null ? text.Invoke(x) : value.Invoke(x),
            Selected = selected == null ? false : selected.Invoke(x)
        });            
    }        
}

With the help of our new SelectListFactory we can now re-write that first block of code as:

Widgets = SelectListFactory.BuildList( db.Widgets.FindAll(), x => x.Name, x => x.Value );

Hmm, not to shabby. However, I think an extension method could make it even cleaner...

public static class SelectListExtensions
{
    public static IEnumerable<SelectListItem> BuildList<T>(
            this IEnumerable<T> items,
            Func<T, string> text,
            Func<T, string> value = null,
            Func<T, Boolean> selected = null
        )
    {
        return SelectListFactory.BuildList(items, text, value, selected);
    }
}

So now lets rewrite the method using our new extension method...

Widgets =  db.Widgets.BuildList( x => x.Name, x => x.Value );

Now that is considerably better than what we started with! Happy Coding!

MVC–Showing a setup screen on the first run

Sat, 09 Jul 2011 02:16:00 -0200

Recently, I participated in a project where I helped to build a website in Orchard. One of the things that I admire (and there are many) about Orchard is the setup screen that appears the first time you run the site. It’s a nice touch and really makes the site easy to configure. No need to tweak a web.config, create a database or read a 20 page setup guide on how to get started. You just fill out the form and the site is ready…

Of course, I wanted to build something similar for my open source project WeBlog. First, I tried to reverse engineer the orchard code. However, orchard uses a lot of dynamic types and things are heavily abstracted so it was hard to re-use their code for my purposes. Next, I tried to Google for a solution but the only thing I could find was this stack overflow post.

My first thought was to create a base controller class and override the OnActionExecuting method. In that method I could force a redirect if the site was not configured yet. However, I abandoned this strategy because at this point in the process the wrong controller has already been created (the one assigned to the default route) and I basically have to cancel the previous request and redirect. Therefore, I decided to use a custom controller factory instead. This way I can intercept which controller and action should be fired if the site has not been configured yet much earlier in the process. Here is what I came up with:

public class WeBlogControllerFactory : DefaultControllerFactory
{
    public override IController CreateController(System.Web.Routing.RequestContext requestContext, string controllerName)
    {
        if (!SiteManager.Any())
        {
            requestContext.RouteData.Values["action"] = "Index";
            requestContext.RouteData.Values["controller"] = "Setup";
            return base.CreateController(requestContext, "Setup");
        }

        return base.CreateController(requestContext, controllerName);
    }
}

Finally, you will need to register your custom controller factory, just add this line to the application_start method in the global.asax:

ControllerBuilder.Current.SetControllerFactory(new WeBlogControllerFactory());

So now when my application runs the first time I get the setup screen. Sweet!

The code can be viewed here. Please leave a comment if you have an alternative solution.

Dapper.Net - A Micro ORM that puts you back in control

Thu, 12 May 2011 23:48:00 -0200

Its fun to reminisce about how database access has evolved over the years. In the early days I used to write parameterized SQL statements directly in my code. Eventually that evolved into using stored procedures. Mainly because by using a stored procedure I could change the way data was gathered without recompiling my source code. Eventually, I abandoned stored procedures altogether when LINQ to SQL was released. Finally, if we fast forward to the current day, my preferred method of accessing data is with EF code first. EF Code first is great because I can spend even less time managing my database and more time solving business problems. With the level of abstraction getting higher and higher it makes you wonder if perhaps the next generation of developers will not even write T-SQL anymore. They will probably laugh at us old timers when we talk about stored procs and T-SQL.

Wait! Back up a minute! Just because we have abstracted ourselves from the database doesn’t mean that we have evolved into something superior. In my past life as a DBA, I spent many of long afternoons diagnosing performance issues. Most of the issues were due to auto-generated SQL statements from an ORM. Sometimes you could put a band-aid on the problem by adding a few indexes or modifying the source code to force different SQL to be produced. However, I was always frustrated by the fact that I had to trade abstraction for performance. Wouldn’t it be nice to have both….

Well you can. Sam Saffron, one of the geniuses at Stack Overflow, came up with a micro ORM called dapper dot net. Dapper dot net is a single file that you can drop into your project that will extend your IDbConnection interface. As I have said so many times before, let’s have the code do the talking.

Executing a query and mapping the results to a strongly typed list

public class Dog
{
    public int? Age { get; set; }
    public Guid Id { get; set; }
    public string Name { get; set; }
    public float? Weight { get; set; }

    public int IgnoredProperty { get { return 1; } }
}            
            
var guid = Guid.NewGuid();
var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });
            
dog.Count()
    .IsEqualTo(1);

dog.First().Age
    .IsNull();

dog.First().Id
    .IsEqualTo(guid);

Notice that strange stuff in the middle. Yeah, that’s called a SQL Statement. Anyways, my point is that we get full control over our SQL statement and in addition we also get a strongly typed result set. Pretty sweet huh?

Multi-Mapping

var sql = 
@"select * from #Posts p 
left join #Users u on u.Id = p.OwnerId 
Order by p.Id";
 
var data = connection.Query<Post, User>(sql, (post, user) => { post.Owner = user; });
var post = data.First();
 
post.Content.IsEqualTo("Sams Post1");
post.Id.IsEqualTo(1);
post.Owner.Name.IsEqualTo("Sam");
post.Owner.Id.IsEqualTo(99);

This is an example of mapping a single row to multiple objects. In EF or Linq to SQL you would accomodate this functionality by leveraging a foreign key relationship. Once again, we have full control of the SQL and strongly typed results.

Multiple Results

var sql = 
@"
select * from Customers where CustomerId = @id
select * from Orders where CustomerId = @id
select * from Returns where CustomerId = @id";
 
using (var multi = connection.QueryMultiple(sql, new {id=selectedId}))
{
   var customer = multi.Read<Customer>().Single();
   var orders = multi.Read<Order>().ToList();
   var returns = multi.Read<Return>().ToList();
   ...
}

Multiple resultsets, a single trip to the server and full control of the SQL. Need I say more?

So Should You Abandon Your Current ORM?

In my opinion, a developer should never settle on a single tool. Being abstracted from the nitty gritty details of writing SQL allows a developer to be more productive. In addition, if you are building small to medium size applications you can afford a small performance penalty because you are probably not dealing with tons of data. Unfortunately, you can't always predict the future of your application. You may start out with 10 users and end up with 10 thousand users. So perhaps the strategy is to develop most of your application using an ORM like EF Magic unicorn and then use Dapper for the parts of your application that need to be performant. This way you get the best of both worlds!

Building a Nuget Server with gold plating

Tue, 05 Apr 2011 00:32:08 -0200

Last week, Phil Haack wrote a post on how to build a NuGet Server. A NuGet server is really easy to build because 90% of the work is done by running a NuGet command. Just for fun, I decided to add some extra functionality to my NuGet Server such as a package upload form and a formatted list of packages.

In preparing my NuGet server, I followed Phil’s direction to a tee except for the fact that I used a “empty MVC 3 app with Razor support” instead of using a “ASP.NET Empty Web Application”. Out of the box, you will get a barebones, but fully functional NuGet server that provides the package list in Atom Format. For each package in the repository you will get access to properties such as the version number, license information, tags and etcetera. However, since I am not a fan of reading XML I thought it would be useful to transform that XML into HTML using XSLT. This way I can see the list of available packages without opening up Visual Studio. XSLT is one of those technologies that I have always read about but never used. So in the spirit of learning I decided to give it a try.

XSLT stands for Extensible Stylesheet Language Transformation. The basic concept is to take a XML file and apply a series of transformations to the underlying data which produces a human-readable HTML file. In order to get this working, I leveraged Tomas Peczek’s XmlActionResult class. Since Tomas did all the hard work, it’s just a matter of loading an XML doc, assigning it to an XmlActionResult and specifying the Transform Source:

[ChildActionOnly]
public ActionResult PackageList()
{
    var doc = new XmlDocument();
    string path = GetUrl("/nuget/Packages").ToString();
    doc.Load(path);
    var result = new XmlActionResult();
    result.Document = doc;
    result.TransformSource = Server.MapPath("~/Content/xsl/packages.xsl");
    return result;
}

From the code snippet above, you can see that I created a XML transformation file named packages.xsl. I then applied the XSL file to the “Atom” package feed. Unfortunately, learning XSLT is a subject too large for me to try to cover in a single blog post. However, the basic concepts are simple and I was able to come up with a working prototype in about 10 minutes. If you are new to XSL, I would recommend reading he tutorials at W3Schools. Also notice, that I added the ChildActionOnly attribute to my controller method. This means that this content can only be called by using the Action or RenderAction HTML Helper method. Since I am using a master page in my solution, I only render the inline HTML markup for part of the view instead of a complete HTML document. Here is the markup for the view which displays the package list. As you can see, it’s just a dead simple Razor page that uses the Html.Action helper method to inject the HTML returned by the PackageList method into the view.

@{
    ViewBag.Title = "Index";
}

<h4>Packages</h4>

@Html.Action("PackageList")

Here is a screenshot of the Package list page. You may notice that one of the packages below is an Orchard widget that I created. I will be blogging more about Orchard development in the near future so stay tuned…

Besides a formatted package list I also added an upload form. This was a simple task of taking the uploaded file and saving it to the packages directory of the web site. Here is a screenshot:

If you are interested in using this code for your own purposes you can download the full source code here via BitBucket. If you want to add any cool features to the server then I will be happy to grant access to the repository. Enjoy!

MVC Tip - An easy way to deal with those NotFound Errors

Fri, 04 Feb 2011 00:11:54 -0200

My first introduction to MVC was the Nerd Dinner tutorial. From that tutorial I adopted the concept of redirecting the user to a “NotFound” page when a item was requested that does not exist. Here is an example of a controller action that returns the “NotFound” view:

public ActionResult Activate(int id)
{
    User user = _repository.FindById(id);
    if (user == null) return View("NotFound");
    //other code....
    return View("Activated");            
}

However, a problem may come into play when you try to encapsulate logic in a model class. For example, let's suppose I have a class named EditUserViewModel which loads the details for a user account. The constructor takes a repository and an integer value which represents the primary key used in the database.

public class EditUserFormViewModel
{
    public EditUserFormViewModel( IUserRepository repository, int id  ) : base()
    {            
        var user = repository.FindById(id);                
        //Load properties...
    }    
}

This is cool because the logic is now hidden inside the model class which has the desirable side effect of keeping the controller lightweight:

public ActionResult Edit(int id)
{
    var model = new EditUserFormViewModel(_repository, id);            
    return View(model);
}

The only issue now is that the code that retrieves the user from the repository is inside the model class. This means that I can no longer can easily check if the user is null and return the request to the NotFound page. So as a result, I came up with this simple solution. The first step is to create a new custom exception class called NotFoundException:

public class NotFoundException : Exception
{
    public NotFoundException() {}

    public NotFoundException( string message ) 
        : base( message )
    {            
    }

    public NotFoundException(string message, Exception innerException)
        : base(message, innerException)
    {
    }
}

Next, inside the EditUserViewModel, when a repository call returns a null object, I throw a NotFoundException:

public EditUserFormViewModel( IUserRepository repository, int id  ) : base()
{            
    var user = repository.FindById(id);
    if( user == null ) throw new NotFoundException();
    ...
}

Finally, since I am always use a base controller class, I can easily add a little bit of "centralized" code to streamline the process of handling all those potential NotFoundExceptions. I start by creating a new method named NotFound(). The NotFound() method has two purposes:

It creates a strongly typed reference to the NotFound view which can be used in any of my controllers. So if I decide to return the NotFound view anywhere in my application I can call NotFound() instead of View("NotFound").
I override the OnException in the base controller class so whenever a NotFoundException is thrown I automatically redirect the user my NotFound view by calling the NotFound() method.

Here is the code:

public class ApplicationController : Controller
{
    public ActionResult NotFound()
    {
        return View("NotFound");
    }

    protected override void OnException(ExceptionContext filterContext)
    {
        if (filterContext.Exception is NotFoundException)
        {
            filterContext.Result = NotFound();
            filterContext.ExceptionHandled = true;
            return;
        }

        base.OnException(filterContext);
    }

    ...
}

Anyway, I thought this was a great approach to handling NotFound errors. Hopefully you will find it useful too.

ASP.NET MVC Unit Testing with UpdateModel and TryUpdateModel

Tue, 25 Jan 2011 23:45:00 -0200

Last week I was in the middle of re-writing an old MVC application. The app was written during the early days of MVC, and as a consequence it was a playground for learning and experimentation. As a developer, I am continuously learning new tricks so its’ no surprise that when I look at the code I wrote a few years ago I often refactor it. For example, when I started out with ASP.NET MVC I did not fully understand how the model binders worked. Unfortunately, this meant that some of my controller actions ended up looking like this:

[HttpPost]
public ActionResult Edit( Guid id, FormCollection form )
{
    var foo = new SomeModel();
    foo.Id = id;
    foo.Name = form["Name"];
    foo.Date = DateTime.Parse(form["EffectiveDate"]);
    foo.Description = form["Description"];
    ....

    if (ModelState.IsValid)
    {
        ...Save and redirect
    }

    return View(model);            
}

Yuck! Referencing form collections in your controller are a major no no! The problem with using a form collection is that it is not strongly typed and it is prone to errors. Its easy to make a typo or get your controller action out of sync with your view. Therefore it is preferred when you can bind directly to a view model or utilize the UpdateModel or TryUpdateModel methods to parse the form. For example the code above can be rewritten as:

[HttpPost]
public ActionResult Edit( Guid id )
{

    var foo = new SomeModel();
    UpdateModel( foo );

    if (ModelState.IsValid)
    {
        ...Save and redirect
    }

    return View(model);            
}

As you can clearly see, the implementation is cleaner and requires much less maintenance by the developer. Anyways, as I continued on my quest to refactor old code, I made it a point to add some unit tests so I could ensure that my refactoring efforts did not break any existing functionality:

[Test]
public void Edit_Post_Action_Updates_Model_And_Redirects()
{
    //Arrange
    var repository = new FakeRepository();
    var foo = new SomeModel() { Id = 1, Name = "Test", Date = DateTime.Parse("1/1/2010"), Description = "Bar" };     
    _repository.Add( foo);

    var model = new SomeViewModel(_repository, foo.Id);
    var controller = new MyController(_repository);
    
    //Act
    var result = controller.Edit(foo.Id, model) as RedirectToRouteResult;

    //Assert
    Assert.IsNotNull(result);            
    Assert.AreEqual( result.RouteValues["action"], "Index" );

    var updated = repository.SingleOrDefault( x => x.Id == 1 );
    Assert.IsNotNull(updated);
    Assert.AreEqual(updated.Name, "Test" );
    Assert.AreEqual(updated.Date, DateTime.Parse("1/1/2010") );
    Assert.AreEqual(updated.Description, "Bar" );
}

Unfortunately when I ran the unit test, the following error was thrown during the call to UpdateModel.

System.NullReferenceException : Object reference not set to an instance of an object.

Luckily, I have run into this problem before so I knew how to fix it. However, I know that not everyone has leveraged Unit Testing in MVC before. So I thought I would document the steps that are required to successfully test a method that utilizes TryUpdateModel or UpdateModel:

You need to fake out the controller context. This can be easily done my adding a reference to Moq and taking advantage of the MvcMockHelpers created by Scott Hanselman. The helper class is used to fake out things like the HttpContext. The magic is all secretly contained in the SetFakeControllerContext extension method.
You need to fake out the form values. Why, because at runtime, the model binder associates form values with model properties via reflection. In other words, if you have a textbox with named “FirstName”, a call to UpdateModel will automatically associate it with the model’s property of the same name. This is the exactly the same as what we did in the first example, when we explicitly set the model.FirstName = form[“FirstName”].

Here is the updated unit test that runs successfully:

[Test]
public void Edit_Post_Action_Updates_Model_And_Redirects()
{
    //Arrange
    var repository = new FakeRepository();
    var foo = new SomeModel() { Id = 1, Name = "Foo", Date = DateTime.Parse("1/1/1999"), Description = "Bar" };     
    _repository.Add( foo);

    var model = new SomeViewModel(_repository, foo.Id);
    var controller = new MyController(_repository);
    controller.SetFakeControllerContext();
    
    //Act
    var result = controller.Edit(foo.Id, model) as RedirectToRouteResult;
    controller.SetFakeControllerContext();

    var fakeForm = new FormCollection();
    fakeForm.Add("Name", "Hello");
    fakeForm.Add("Date", "1/1/2010");
    fakeForm.Add("Description", "World" );
    controller.ValueProvider = fakeForm.ToValueProvider();
    
    //Assert
    Assert.IsNotNull(result);            
    Assert.AreEqual( result.RouteValues["action"], "Index" );

    var updated = repository.SingleOrDefault( x => x.Id == 1 );
    Assert.IsNotNull(updated);
    Assert.AreEqual(updated.Name, "Hello" );
    Assert.AreEqual(updated.Date, DateTime.Parse("1/1/2010") );
    Assert.AreEqual(updated.Description, "World" );
}

In conclusion, try to avoid using form collections and take advantage of the model binding that MVC has provided us with. If you are not unit testing your controllers then you should start immediately. Although unit testing may cost you some extra work up front, you should see a return on investment due to a reduced bug rate. In addition, when you have good test coverage you will rest assured at night knowing that your code is stable and in proper working order.