Putting Lipstick on a Web Site

To start with there are a few ground rules and goals to establish. One is that a 301 permanent redirect is desirable from older urls onto new routed urls. Another is that not all urls in the app need to be fixed “in place” in the original html response assuming the 301 redirects will keep the resulting urls canonical. Third is that it’s highly desirable to be able to calculate the new route given an old url server-side, for such things as the site map and updating the links on pages which are particularly significant.

Another consideration is that if a site is currently using Request.QueryString values and relies on postback, both of those should continue to work transparently. A final consideration is the range of possible values in a piece of the route could be driven by a database or source which is non-static or has a huge number of possible distinct values. At least a number too large for adding multiple routes or combining into regex restriction.

Downloads: retrofit.zip source code and sample project.

It turns out the System.Web.Routing module is particularly well suited for this, especially because of the bidirectional nature of it’s routes. The attached solution has a sample web app and a class library named Retrofit.Routing which provides an example of using System.Web.Routing in this way.

First of all is the class Retrofit.Routing.WebFormsRouteHandler which implements IRouteHandler. You’ll find in it’s implementation the method GetHttpHandler which will use BuildManager.CreateInstanceFromVirtualPath to obtain an instance of the targetted web page. The web page is targetted with the RouteData Value parameter named “VirtualPath”, much like in an MVC app the controller is targetted with a RouteData Value named “Controller”. The other thing this class does is call HttpContext.RewritePath to extend the number of values present on the QueryString.

You won’t use the WebFormsRouteHandler directly, instead you’ll create an instance of WebFormsRoute. This WebFormsRoute is a descendant of the standard Route class and is used in almost exactly the same way.

public static void RegisterRoutes(RouteCollection routes)
{
    // enable routing of existing files so WebFormsRoute has the chance redirect old urls
    routes.RouteExistingFiles = true;

    // matches customer with a data-driven constraint
    routes.Add(new WebFormsRoute(
        "Customer/{*CompanyName}",
        new RouteValueDictionary(new {VirtualPath = "~/Contacts/Customer.aspx"}),
        new RouteValueDictionary(new {CompanyName = new ValidCompanyNameConstraint()})
    ));

    // matches orders requests
    routes.Add(new WebFormsRoute(
        "Customer/Orders/{OrderID}",
        new RouteValueDictionary(new {VirtualPath = "~/Orders/Details.aspx"})
    ));

}

As we can see defaults can be provided, which is how the value for VirtualPath is defaulted in when a request pattern is matched. The values like {CompanyName} and {OrderID} which are matched above will become CompanyName= and OrderID= querystring parameters passed to the aspx page as it runs, so the code behind does not need to be modified for those cases.

There’s even an example above of how you would provide an IRouteConstraint class if you would like to dynamically restrict the set of urls a route is allowed to match.

public class ValidCompanyNameConstraint : IRouteConstraint
{
    public ValidCompanyNameConstraint()
    {
        // pre-load valid company names
        // in a real app this would be queries each call to match,
        // or it would be re-cached when the data had changed.

        var data = new NorthwindDataContext();
        CachedNames = data.Customers.ToDictionary(x => x.CompanyName, x => x.CustomerID);
    }

    private Dictionary<string, string> CachedNames { get; set; }

    public bool Match(HttpContextBase httpContext, Route route, string parameterName, RouteValueDictionary values, RouteDirection routeDirection)
    {
        var parameterValue = Convert.ToString(values[parameterName]);
        return CachedNames.ContainsKey(parameterValue);
    }
}

It’s a contrived example, but it is just a sample after all.

And the WebFormsRoute is performing one other task related to the need for 301 redirects. As requests are coming in it’s not only matching the request against the new url pattern, it’s also testing the request url against the old virtual path and query string parameters needed.

    // do the work to check if the incoming request could also produce
    // a meaningful route to redirect towards
    var probeVirtualPathData = TestVirtualPath(httpContext, virtualPath);
    if (probeVirtualPathData == null)
        return null;

    // the request is on a page which this route controls, 301 redirect
    // onto the correct location
    return new RouteData(this, new PermanentRewriteHandler(probeVirtualPathData.VirtualPath));
}

If the incoming request is match for the old url structure then it takes advantage System.Web.Routing’s ability to calculate the correct url in the new pattern. This new url is used as the parameter of a handler which will return a 301 permanent redirect to keep the browser’s address bar clean-looking and to ensure web crawlers are indexing the site with at this single, canonical location.

The rewrite handler itself is a pretty simple device.

public class PermanentRewriteHandler : IRouteHandler, IHttpHandler
{
    private readonly string _path;

    public PermanentRewriteHandler(string path)
    {
        _path = path;
    }

    public IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
        return this;
    }

    public bool IsReusable
    {
        get { return false; }
    }

    public void ProcessRequest(HttpContext context)
    {
        context.Response.Buffer = true;
        context.Response.Redirect("~/" + _path, false);
        context.Response.StatusCode = 301;
        context.Response.StatusDescription = "Moved Permanently";
    }
}

At this point nearly all of the goals are met. You can route incoming requests on new urls onto existing WebForms pages, it will 301 redirect incoming old urls onto the new location, the route values are converted to querystring values transparently, and POST to the WebForms life-cycle will pass through unimpeded on the old or new urls.

The final piece of the puzzle is the need to return the new urls in links returned from pages on the server without relying on the 301 redirects. That’s done easily enough with an extension method Page.ResolveRouteUrl that is used in the same way as Page.ResolveUrl.

public static string ResolveRouteUrl(this Page page, string relativeUrl)
{
    var url = relativeUrl;

    var virtualPathData = GetVirtualPathData(relativeUrl);
    if (virtualPathData != null)
    {
        url = "~/" + virtualPathData.VirtualPath;
    }

    return page.ResolveUrl(url);
}

And it’s used like this:

Company: <asp:HyperLink ID="HyperLink1" runat="server"
                NavigateUrl='<%# Page.ResolveRouteUrl("~/Contacts/Customer.aspx?CompanyName=" + Eval("CompanyName")) %>' Text='<%# Eval("CompanyName") %>'></asp:HyperLink>

Downloads: retrofit.zip source code and sample project.

In a nutshell - duct tape a tongs to the end of a spatula for length. Use the spatula to slice spam into 8mm slices. Place single slice on spatula and wrap around with tin foil, twisting like hard candy wrapper. Cook liberally over fire, unwrap carefully, put on hamburger bun and spray with pressurized cheese in a can. Enjoy.

Brenda swore by them. A warning however - have only one without an antacid on hand.

There was a brilliant fireworks display on the fourth with dozens of cakes of two- and three-inch mortars. Long story short Brenda’s cousin was involved in the show and I was enlisted to be perimeter security. So with flashlights in hand as Brenda and I watched for anyone who would may have wandered up to the launching area and we had point blank view of the show. Didn’t get hit by much debris at all. :)

I was noticing the traffic on the site for Spark project information and documentation has been picking up nicely. That lead me to thinking about bumping up to another notch on the slice size, but that sort of doubles the hosting cost. It’s pretty modest figure but it can add up over the year.

With the hosting costs at the top of my mind I noticed that a number of the blogs I’ve been reading like Haack’s, Hanselman’s, and Felker’s are showing ads from The Lounge. The ads seemed pretty topical too, relating to a tight cluster of dotnet development and web hosting subject matter, so I dropped them a line to see if the volume of traffic I had was on their radar.

Turns out they do have an advertising bundle of open source product sites, like Ninject, which Spark fit into quite nicely. One day later everything’s all hooked up and running.

It’s nice to have a little splash of color on the page too. I didn’t realize it at the time (paging through all of the Drupal themes of all shape and color) but that particular theme is pretty stark on pages where the blue info block isn’t present.

Coinciding with the release I did a presentation of Spark on the 18th for the Minneapolis ALT.NET group organized by Freemind.

I had mentioned I was preparing for this and someone on Twitter asked if it would be recorded, so I arranged for a camcorder to be present.

Downloadable materials:
PowerPoint slides
All files and projects
New Downloadable version at 1024×768, 982.21MB

There were some lessons learned. One is that CamStudio will record as long as you like, then fail when it’s compressing and interleaving audio if the result is larger than 4GB.

Fortunately, out of a deep-seated (and apparently justified) distrust of technology there was also a camcorder on a tripod. An Avisynth filter named Reform provided some fairly acceptable results reconstructing a 4:3 aspect ratio of the screen.

There is an additional 30 minutes of audio captured by CamStudio after the tape ran out. I’m thinking of recapturing a video to go with that.

Earlier Brad Wilson speculated:

Theory: in ASP.NET MVC, master pages cause users to use ViewData instead of strongly typed models more often than any other reason.

To which I replied:

@bradwilson That, plus keeping properties in sync on a class that exists only to stand between an action and view isn’t very DRY

It’s true there are a huge number of reasons to need data in a master layout like navigation, sidebar widgets, current user profile, ad codes, etc. But if that was the main cause should be pretty easy to address by having the master layout’s data in a layer superclass for all of your action-view models.

I believe another even more serious problem is the view model can make you repeat yourself a huge number of times.

One of the things that’s really nice about actions on a controller is you can avoid the proliferation of classes you get with the command pattern. If you make a model for each action you get that problem back in spades. You could keep track of commonality between actions to reduce the number of action/view model classes, but that’s more work and you’re playing a balancing act between how many classes you are making and how many unused properties are acceptable for actions that don’t produce strictly identical data.

Plus it’s not DRY… I’ve added the action to a controller, then I need to add the class to hold the data. I’ve acquired some data in the action, then I need to add the typed property to the action’s model. Some data’s refactored out of the action, then I need to remember to remove it from the data bucket class too.

Just to throw an idea out there, to have a DRY action-view model class, how about adding the idea of a dynamic partial class to the language? A partial class which merges with additional auto-implemented properties at compile-time, as a result of the property assignments on that type.

So here’s that you would have today. The following assumes DefaultMasterData members will be assigned by filters if the model has an appropriate base class.

public class DefaultMasterData
{
	public UserProfile Profile {get;set;}
	public string AdvertisementCampaignCode {get;set;}
}

public class HomeIndexData : DefaultMasterData
{
    public Product Product {get;set;}
	public Order CurrentOrder {get;set;}
}

[UserProfileFilter]
[AdvertisingFilter]
public class HomeController
{
    public ActionResult Index()
    {
		...acquiring stuff here...

		// return view of model
	    return View(new HomeIndexData {Product = mostRecentProduct, CurrentOrder = activeSessionOrder});
    }
}

Here’s if you had a dynamic partial class. The assignment of non-existant properties results in an implicit partial with auto-implemented properties to be merged in at compile time.

public class DefaultMasterData
{
	public UserProfile Profile {get;set;}
	public string AdvertisementCampaignCode {get;set;}
}

public dynamic partial class HomeIndexData : DefaultMasterData
{
}

[UserProfileFilter]
[AdvertisingFilter]
public class HomeController
{
    public ActionResult Index()
    {
		...acquiring stuff here...

		// return view of model
		// creates implicit partial with auto-implemented properties
	    return View(new HomeIndexData {Product = mostRecentProduct, CurrentOrder = activeSessionOrder});
    }
}

And to kill just a bit more code, how about a the ability to declare the named type without the empty class statement?

public class DefaultMasterData
{
	public UserProfile Profile {get;set;}
	public string AdvertisementCampaignCode {get;set;}
}

[UserProfileFilter]
[AdvertisingFilter]
public class HomeController
{
    public ActionResult Index()
    {
		...acquiring stuff here...

		// return view of model
		// creates implicit partial with auto-implemented properties
		// also results in the initial declaration of the type HomeIndexData based on DefaultMasterData
	    return View(new dynamic partial HomeIndexData:DefaultMasterData
	        {Product = mostRecentProduct, CurrentOrder = activeSessionOrder}
	    );
    }
}

There! Now I think you’ll see people using a base of ViewPage<HomeIndexData> in Index.aspx.

Clearly there are lots of questions about namespace, etc., but you get the idea.

Final note, to declare an anonymous type with a base class, it would be nice to support something like.

var x = new :MyBase {Foo="bar", Frap=5};

Another final note - you wouldn’t need to do it all inline of course.

[UserProfileFilter]
[AdvertisingFilter]
public class HomeController
{
    public ActionResult Index()
    {
	    var model = new dynamic partial HomeIndexData:DefaultMasterData();

		...acquiring stuff here...

		// assignments causing more auto-impl props here
	    model.Product = mostRecentProduct;
	    model.CurrentOrder = activeSessionOrder;

		// return view of model
	    return View(model);
    }
}

If you’ve used a folder synchronizing tool before that will propogates file changes between machines, like FolderShare or DropBox, there’s a good chance you’ve had a scare with some possible data loss. Maybe you accidentally dropped a folder into a subfolder, “made space” by getting rid of files on one of the machines, or the sync software went crazy. Whatever the case is the change is immediately shipped onto all of your backups all over the world.

That effect makes file sync tools more of a convenience than a backup strategy - it can lower your mean time to recovery in case of hardware failure - but even though there are two or more physical copies of your bits there’s really one logical copy that appears in several places where it can be accidentally deleted. Ironically the convenience of having your data everywhere also lowers it’s mean-time-to-accidental-destruction.

Which is exactly the problem a change control repository like Git is designed to solve! Fearing data loss as much as the next person, I tried to combine the convenience of Live Mesh with the safety of Git and it worked really well. Here’s how it went, assuming you have msysGit and Live Mesh installed on your machine.

Update here’s a diagram of what we’re ultimately going to try to accomplish.

Initialize Git

First off - the goal is not to put a Git repository into a Live Mesh folder. Git already has a push-pull mechanism to move changes around and the word is Live Mesh will just trash your repos files by moving overlapping changes over each other on different nodes. Instread what we’ll be doing is creating a new Git repository and using a Live Mesh folder as it’s working copy.

:create a new folder to hold files
mkdir "%userprofile%\Documents\Junk Drawer"

:go to it
cd "%userprofile%\Documents\Junk Drawer"

:initialize a repository
git init

:mark the .git subfolder hidden
attrib +H .git

Or if you prefer to avoid command-line you can do the same thing with Git GUI and Explorer.

Initialize Live Mesh

Then the magic happens - add the Junk Folder to Live Mesh.

Throw some files in there and they’re automatically synchronized onto Live Desktop online (and to other devices which you have synchronizing the Junk Drawer). The Live Desktop gives you a browser-based Explorer-like interface to your files.

You can now access and modify the files in the Junk Drawer from any number of devices, including downloading and uploading files through mesh.com. All changes will be synchronized at every location including the one we originally created which is the working directory of the Git repository.

Commit Changes

Git keeps track of your files in the working folder when you select the changes to stage, provide a comment, and hit commit. Because it’s all synchronized it doesn’t matter which device caused the changes. There are plenty of Git tutorials out there so I won’t go through all the steps of adding files and committing them, looking at history, restoring files from source control. In the end the point is that this Git repository is now providing change control tracking for my Junk Drawer folder and (by extension) all devices on the Mesh hosting that folder even if they don’t know it.

Push Changes

If we stopped here there would be a history and some protection against accidental deletion (because you can get the files out of Git if they disappear) but there’s still a risk we’re exposed to. All of the repository data is saved in the hidden “Junk Drawer\.git” folder which could be lost if the drive fails or if the Mesh goes insane and wipes out the entire Junk Drawer parent folder.

Fortunately it’s a really easy problem to take care of - from this git repository simply initialize a new remote repository and push all changes to it. Okay, maybe it’s a little tricky to get set up because msys and git are a bit… awkward… when it comes to drive letters and such. So here are the commands you’ll use to create a remote repos on a known UNC.

:map a drive long enough to initialize an empty repository.
:use whatever unc and drive letter is appropriate for you
net use G: \\10.0.0.3\storage

:go into the working folder
cd "%userprofile%\Documents\Junk Drawer"

:and create a bare repository on the file server
:use whatever folder name makes sense
:the foldername.git extension is conventional for Git repositories
:that don't have a working copy of the files checked out
git clone --bare . G:/junk.git

:unmap the drive letter
net use /delete G:

:inform the local repository that "origin" refers to this new unc git location
git remote add origin //10.0.0.3/storage/junk.git

:and finally push over to the "origin" repos everything on the default "master" branch
git push origin master

Once the association between the local and remote repos is established you can push to it from Git GUI any time you commit changes on your mesh.

Conclusion
And there you have it!

* You can have a Live Mesh folder synchronized between any number of devices.
* Each device can create, access, and modify those files normally without being aware of change-control
* You can commit changes on your mesh folder into a Git repos exactly as if it was a working folder
* You can push commits to an even more rugged Git repos on a distinct and isolated storage location

And now your files are safe - even if Live Mesh goes completely insane destroying all of your files and the hidden .git folder inside the original device’s Live Mesh folder. All you need to do is clone the Git repos down from the storage location back onto your hard drive and you’ll have all of the changes you pushed earlier in a new local repos and a rebuilt working folder filled with all of your files. Mark the new .git folder as hidden again, add the working folder back into Live Mesh, and you’re up and running again.

# 113 - Saying Hello to the Spark View Engine

In this episode we are going to start a series where we take an indepth look at the Spark View Engine.

Spark is a view engine for Asp.Net Mvc and Castle Project MonoRail frameworks. The idea is to allow the html to dominate the flow and the code to fit seamlessly.

Very cool. Can’t wait to see it on a pc with audio.

It also reminds me I need to revamp the front page of the project site. I’d like for it to start with something like a quick article about creating a spark app instead of a bunch of random links.

Matt makes a particularly insightful remark in a comment, “what I dislike is how the balance of language in the helpers tends to shift from C# to JavaScript or HTML.”

I’d agree with that. On the one hand you’re trying to avoid excessive code in your template, but in doing so you’re dragging markup into your code. It’s actually a great example of a primary use-case for a macro in the Spark language, which lets you declare a helper method in the template language.

Here is the HtmlHelper extension exactly as it appeared on Matt’s post:

/// <summary>
/// Renders JavaScript to turn the specified file input control into an
/// Uploadify upload control.
/// </summary>
/// <param name="helper"></param>
/// <param name="name"></param>
/// <param name="options"></param>
/// <returns></returns>
public static string Uploadify(this HtmlHelper helper, string name, UploadifyOptions options)
{
    string scriptPath = helper.ResolveUrl("~/Content/jqueryPlugins/uploadify/");

    StringBuilder sb = new StringBuilder();
    //Include the JS file.
    sb.Append(helper.ScriptInclude("~/Content/jqueryPlugins/uploadify/jquery.uploadify.js"));
    sb.Append(helper.ScriptInclude("~/Content/jqueryPlugins/uploadify/jquery.uploadify.init.js"));

    //Dump the script to initialze Uploadify
    sb.AppendLine("<script type=\"text/javascript\">");
    sb.AppendLine("$(document).ready(function() {");
    sb.AppendFormat("initUploadify($('#{0}'),'{1}','{2}','{3}','{4}','{5}',{6},{7});",
                    name, options.UploadUrl,
                    scriptPath, options.FileExtensions,
                    options.FileDescription, options.AuthenticationToken,
                    options.ErrorFunction ?? "null",
                    options.CompleteFunction ?? "null");
    sb.AppendLine();
    sb.AppendLine("});");
    sb.AppendLine("</script");

    return sb.ToString();
}

And here’s the same helper implemented as a macro:

<macro name="Uploadify" name="string" options="UploadifyOptions">

  <var scriptPath="Html.ResolveUrl('~/Content/jqueryPlugins/uploadify/')"/>

  !{Html.ScriptInclude("~/Content/jqueryPlugins/uploadify/jquery.uploadify.js")}
  !{Html.ScriptInclude("~/Content/jqueryPlugins/uploadify/jquery.uploadify.init.js")}

  <script type="text/javascript">
    $(document).ready(function() {
      initUploadify($('#!{name}'), '!{options.UploadUrl}',
        '!{scriptPath}', '!{options.FileExtensions}',
        '!{options.FileDescription}', '!{options.AuthenticationToken}',
        !{options.ErrorFunction ?? "null"},
        !{options.CompleteFunction ?? "null"});
    });
  </script>

</macro>

The usage of the helper remains nearly identical. It’s a method on the view now instead of an Html extension method… So:

<%= Html.Uploadify("fileInput", new UploadifyOptions { ... }) %>

becomes:

<%= Uploadify("fileInput", new UploadifyOptions { ... }) %>

or rather:

!{Uploadify("fileInput", new UploadifyOptions { ... })}

Upgrade went well - some config files showed up as modified so there were some keep/replace prompts. But in general pretty smooth.

Did lose the php-fastcgi daemon in the upgrade though. So that was a bit of a rough moment after the reboot when both http://whereslou.com and http://sparkviewengine.com were toast.

Fortunately a quick Google search turned up this blog post from Elderec which got me up and running again.

The initial work for engineering began some time last year, approximately December, we began to create systems known to be necessary for the functionality that would be eventually required. The middle of the first quarter saw the completion of the joint efforts of the design agency and business stakeholders in the form of new IA/UX and design. With an ultimate target date of May 12th I’m sure you can appreciate the fact a huge number of things about the implementation needed to go very well.

Many people on several teams were involved in it’s creation. I can’t possibly name everyone involved but I wanted to recognize a few people who acted in a technical leadership capacity.

Kevin Dotzenrod, Architect and Engineer Manager, is a good friend I’ve worked with many times before. He was instrumental in the success of the project in every way from the original solution design to final profiling and field integration.

Donn Felker, Senior Consultant with Magenic, is a developer I was working with for the first time but respect greatly. His fluency in the art modern software development, determination, and ability to knock down complex challenges is incomparable.

And the team leads, Kevin Boedigheimer, Peter Gaard, Bob Galuska, Ben Music, and Phil Whipps, have done a spectacular job of engineering individually as well as ensuring the people on their teams could be successful.

But enough cheerleading. :)

Platform

We made the decision in the very beginning to shift onto IIS7 on the Windows Server 2008 64-bit platform. Some notable technologies used in the site’s creation include ASP.NET MVC, Spark, WCF, Windsor container, and Active Record over NHibernate.

That may seem like a risky combination, but the ASP.NET MVC web framework was the only technology we hadn’t used in production previously. Everything else had a proven track record of stability and ease of use. Because we were transitioning from MonoRail+Spark to MVC+Spark even that change didn’t involve any differences in concepts and patterns. The learning curve was limited to the differences between in controllers, routing, and html helper implementations. The extensibility of System.Web.Mvc and System.Web.Routing was particularly impressive. With the ability to replace a service at exactly the correct place you can take command of your controller creation to introduce IoC, or your take control of the action/result execution process to inject site-wide filters or policy.

Although the technology was understood a few rough patches for productivity came during the earlier stages of development, which is why you always want to keep an eye out for opportunities to adapt and simplify. A large number of people were working in parallel, and once certain critical superstructure was in place the velocity of development was astonishing. One practice we adopted which worked quite well was to establish a canary deployment as part the last step of a successful build. Not to be confused with qa deployment, or staging for production, or a snapshot for internal demos - the job of the canary (in the coal mine) is to die first when there’s a new problem. It’s used as a shared resource to verify correctness of recent changes and the current state of the overall project.

Bluegrass

There’s no time to dive into all of the different aspects of the implementation but one I wanted to highlight specifically is Bluegrass. For a long time MarketWatch has had a LiveQuotes feature, which evolved into LiveSuite as news was introduced, both of which are now deprecated with with the deployment of Bluegrass - our asynchronous, comet-like distribution framework to deliver instantaneous json data and event information. The client forms at-most-one connection with the a message broker which either returns queued messages or enters an efficient aync wait state on the server until the arrival of messages for that particular caller.

The brokers themselves are ignorant of the meaning of the messages, a change from the design of LiveQuotes and LiveSuite, which will enable us to provide additional channels of information without updating and redeploying those systems. The scale at which they operate is also unprecedented in our organization. The servers will each process 3700 requests a second at sixty percent cpu (dual quad-cores) and will top out at six thousand. And that’s while each server averages over ten thousand concurrent requests executing as several calls to pickup are “on hold” pending the arrival of any messages for the caller.

Windsor

For the implementation of the web site itself there were many reasons to keep it simple and direct. Windsor is an Inversion of Control (IoC) container which are very important to understand if you haven’t used such a thing before. It’s impossible to describe why you would want to use an IoC container other than to describe it’s effect with a metaphor. Imagine in your mind the classic surgery scene - the surgeon says “scalpel” and whap she has one in her hand, properly sterilized and inventoried pre-op according to policy, so all she does is indicates the need and uses the tool. “Clamp” and whap she’s clamping. Doesn’t even glance away from the surgery site.

The effect this has on your code is dramatic. As you’re writing a controller it has a task at hand to worry about. It’s concern is receiving actions and their parameters and policy, composing view data, returning the appropriate type of result in response. The last thing you need is a lot of code, and the associated knowledge, for create and initializing the services it needs. Just as a surgeon doesn’t sterilize and inventory the O.R. equiptment she’ll be using, an IoC container enables your controller’s constructor to say “IQuotes,” “IHeadlines,” “IComments,” and have the appropriately initialized and lifecycled implemenations of those service components slapped into it’s hands ready to use.

It’s a beautiful thing and really helps you abstract away the complexity of interconnectedness with very little effort on what is a fairly large number of components coming together to service a request. We had declared a base IService interface to automatically enlisted the descendant components into the IoC container and that convention eliminated all configuration in the majority of cases.

There’s more I could go on about - but this is blog, not a short story, so at this point I believe I’ll thank you for reading this far and leave it at that. :)