Monthly Archives: April 2011

Dependency Injection with Ninject and Mocking with MoQ

Today it’s my great pleasure to lead the discussion about Dependency Injection with Ninject and Mocking with MoQ at the SEVDNUG.

Our purpose as software developers is to orchestrate together loosely coupled, well tested components.  Yet far too often, our code turns into a big ball of mud.  These two tools and their supporting techniques can create loosely coupled, eagerly testable code that will make you much more productive.

Our starting place is this, an n-tier app with hard-coded dependencies.  This is very hard to unit test.  I grant there’s good separation of concerns here, and that typically that’s harder than it looks.  After a brief discussion of the architecture of this app, we’ll look for seams in the code — places where we can insert interfaces and separate the dependencies.  We’ll make the adjustments with the help of Resharper, then get Ninject to wire up the dependencies for us.  With dependencies solved, we’ll look at unit testing various pieces (time permitting).  We’ll instantiate the code under test, and mock the dependencies using MoQ.  Once we’re done, we’ll end up with something similar to this, an app with loosely bound dependencies, a clean separation of concerns, and good test coverage.  Even more important, we will understand the purpose and benefits of Dependency Injection, and have a firm, practical grasp of how to accomplish it.  We’ll also have a firm understanding of mocking, and practical tools at hand to make unit testing easy.

Where can you go from here?  Let’s look at unit testing routes, integration testing, continuous integration, etc.  The sky’s the limit.


HtmlHelper for something that isn’t the Model in ASP.NET MVC

I’m in the midst of a Razor View, and I want to use things like

@Html.EditorFor(model => model.ProductId)

but the model isn’t a Product, it’s a composite type for this view that looks like this:

public class SomeViewModel {

    public Product Product { get; set; }

    public List<Irrelevant> IrrelevantList { get; set; }


Well, I can say

@Html.EditorFor(model => model.Product.ProductId)

but now the markup on my page says

<input type=”irrelevant” id=”Product_ProductId” name=”Product.ProductId” />

Two problems here:
1. That’s ugly.
2. The post ActionMethod takes in a Product, so the model binder doesn’t work right.

I really want an HtmlHelper<Product>

So, I gin one up like so:

var ProductHtml = new HtmlHelper<User>( this.ViewContext, new ViewDataContainer2 { ViewData = new ViewDataDictionary<Product>( Model.Product ) } );

and now I can do this:

@ProductHtml.EditorFor(model => model.ProductId)

System.Web.Mvc.Html.TemplateHelpers.ViewDataContainer would be perfect, but it’s private, so I cloned it as ViewDataContainer2 like so:

public class ViewDataContainer2 : IViewDataContainer {

    public ViewDataDictionary ViewData { get; set; }


Presto, it works.  Both problems are resolved.  Awesome.


CruiseControl.NET home page link to latest build

I often find that I hit the CruiseControl.NET home page, see red on a build, and specifically want the latest build report. I could click the Project Name link then the latest build link, but that intermediate page isn’t buying me much. What I’d really like is the last build time to be a link to this latest build report.

I cracked open the webdashboard folder, and inside the templates directory was the magic sauce. I modified ProjectGrid.vm line 127 from:



    <td><a href=”/server/$projectGridRow.ServerName/project/$projectGridRow.Name/ViewLatestBuildReport.aspx”>$projectGridRow.LastBuildDate</a></td>

and I now click on the last build date link and get straight to the last build report. Awesome.