Until we get our cross-posting in order, I’ll post links here to each of my posts over there, starting with these:

• How we built a service bus for all of our application instances to talk to one another (a series of 5 posts and counting)
• How we got ready for the huge traffic spike on US election night in November 2010
• How much faster Visual Studio is when running on solid state drives

But please subscribe over there to get all the goodies from the whole team.

To all you US citizens over 18:  VOTE!  And then watch the election results as they come in.  Works well on your mobile phone or iPad, too.

The next big question is: How do we divide our CMS into large-grained sets of discrete functionality – business services?

A good CMS cleanly separates content from presentation.  Even simple blog-oriented CMSs have this separation.  This blog is currently hosted in WordPress.  By simply downloading a different WordPress theme, I can change not only colors and fonts, but the entire structure of the site.  I can add widgets to the sidebar, change the header image, show either full posts or excerpts on the main page, add buttons to share on Twitter and Facebook, change URLs or move pages around into an entirely different hierarchical structure – all without touching the content of a single post.

With a large news-oriented CMS, this separation is even more important.  We deliver news not just to browsers, but to all kinds of applications and devices – from iPads to Bing Maps and Google Earth, from Microsoft Surface tables to a 70s-style arcade game machine in Rockefeller Center.  But our reporters and editors shouldn’t have to worry about – or even be aware of – all of that.  They just need to worry about crafting great stories.

Thus, the most obvious business services within our CMS are what we call Editorial and Delivery.

As a news organization, we not only deliver the news – we consume it in enormous quantities.  Feeds like the AP, UPI, Agence France-Presse, and hundreds of other text and photo sources all flow in 24 hours a day.  Then there are data sources like weather, stock market tickers, lottery results, etc.; it all has to be gathered, organized, searched, categorized, edited, and made available for publishing.  Elections produce enormous amounts of data that we need to sort, search, and aggregate.  All of this functionality makes up the Ingest business service.

One type of ingested content absent from the list above is video.  NBC News (a parent of ours) is one of the largest producers of video news content in the world.  We support the websites for msnbc.com, cnbc.com, todayshow.com, plus shows like Rachel Maddow, Countdown, Dateline, Nightly News, Meet the Press, and more.  Video is different from text and photo content in many ways:  sheer file size, bandwidth consumption, encoding standards (and the computing powered needed for encoding), editing tools, advertising model, etc.

As a result of this complexity, video is a technical and editorial specialty unto itself.  I’m no expert in video, so I’ll leave the detailed discussion to others.  But as a major functional area that has to integrate with everything else in our CMS, Video is a business service.

Our other parent (Microsoft) gives us access to a wealth of technology.  Not only the platform building blocks of Windows Server, ASP.NET, WCF, etc.; but also cool stuff like the ability to scan huge amounts of content and determine the most important people, places and concepts mentioned.  And to automatically determine which stories, photos, and videos are related to one another.  Check out the Related and Topics areas near the bottom of a story page to see what I mean.  Like video, we want this capability integrated with many other parts of the system, yet it is more or less a world unto itself.  This is the Topics business service.

With any non-trivial system, we also need to concern ourselves with day to day operations and maintenance.  How do we easily deploy to and configure all those servers in multiple data centers?  How do we monitor them and get notified when something isn’t working?  How do we get detailed troubleshooting data for a server or process gone awry?  While some of these capabilities need to be part of the implementation of every service, the data aggregation, monitoring and notifications are business functionality that forms the Operations service.

In future posts, I’ll dig into these services and their component applications, focusing first on the Delivery service.

As we began work on a new CMS for msnbc.com, one of the major pain points with the existing system that we wanted to address was its database oriented architecture – or DOA.   No, not the popular video game (searching for DOA is borderline NSFW).  Rather, “dead on arrival” – the morbid term for an ambulance patient who doesn’t survive the trip to the hospital.

A multitude of dependencies on a single central database is, indeed, DOA.  First, it doesn’t scale well up to billions of page views per month, or make it easy to achieve redundancy across data centers.  Doing so requires all sorts of magic with clusters, mirroring, replication, etc. – in other words, expensive hardware and even more expensive people.  (The reason it has worked up to now is our top-notch operations team.)

Second, all of those dependencies mean that changes to the database schema are effectively impossible. 

A CMS like ours isn’t a single application.  It’s an ecosystem of applications, built by different teams over a long period of time and performing a wide variety of functions: filtering and aggregating hundreds of inbound news wires in different formats, encoding all the video from one of the largest news organizations in the world, supporting journalists on tight deadlines around the clock, and – oh, yeah – serving up all that content to millions of people a day. 

Most of those applications create or manipulate content that is stored in the central database.  Thus, any change to the database is likely to have side-effects.  A change to support one application, simple on its own, turns out to require a major refactoring effort in an unrelated application.  Fixing bugs becomes a game of whack-a-mole; new features become more expensive and take longer and longer to release.  Worse, a great new feature may not get built at all.

This isn’t really a problem with databases, of course.  It’s a problem with dependency management.  But it is exacerbated by the fact that accessing a database is inherently a blocking operation – you have to wait for the result.  Any single resource that must be available all the time in order for any other part of the system to function correctly is going to cause these types of problems.

For all of these reasons, we opted instead for a service oriented architecture (SOA).  That doesn’t mean simply exposing everything as a web service.  It means partitioning the system into “business services” – large grained, autonomous sets of functionality.  Being autonomous includes having one’s own private database (assuming there is some data for that service to persist).  Private means private – the database is not shared with other services.

SOA is not exactly a radical choice, but it does require a radical change in thinking – for developers, for admins, even for end users.  It requires letting go of 100% consistency 100% of the time in favor of eventual consistency, letting go of “one database to rule them all,” and accepting that maintaining multiple, service-specific versions of the data won’t be the end of the world.

It takes a lot of time and constant effort to completely change your world view.  It’s not unlike a procedural developer being introduced to object orientation.  It takes a lot of practice, and dozens of “Aha!” moments to cross the conceptual chasm.  As an organization, we’re still in mid-air.  I expect we’ll eventually land safely on the other side, and not wind up DOA.

In a future post, I’ll write about how we drew the boundaries between our business services.

The visible part of the change is an entirely new look for stories.  You can take a tour.  There are some great new features, including the ability to easily embed video, like so:

Visit msnbc.com for breaking news, world news, and news about the economy

Alas, I had nothing to do with all those great features…  My contribution was in the invisible parts – the underlying platform on top of which some smart, creative folks have built the new pages.  There’s quite a bit more to it than meets the eye. 

I’ll be posting on a bunch of topics related to what we did, how we did it, and why we did it that way.  The highlight reel will include: SOA, EDA, messaging, service bus, WCF, MSMQ, ASP.NET MVC, unit testing, TFS, performance testing and profiling, Avicode, automated deployments, and a lot more.  To the extent I’m allowed to, I’ll share some code, too.  Stay tuned…

In an event-driven architecture (EDA), business services communicate with one another through asynchronous messaging, in order to reduce the coupling between them.  By communicating asynchronously, a business service can continue to operate (for some period of time) without any contact with other business services.  That’s where their “autonomous” quality comes from.

For example, a retailer might have an Inventory service, an Order service, an Inventory service, a Billing service, and a Shipping service.  The Order service can take orders even if the other services are unavailable.  When those services become available, queued messages can be exchanged — inventory gets allocated, orders get shipped and customers get billed.

Suppose an order is placed over the web.  The Order service might publish an OrderReceived message.  The Inventory service would then publish either an InventoryAssignedToOrder or an ItemOutOfStock message, depending on what was actually available.  The Order service would subscribe to those types of messages.  If it received the first, it would then publish an OrderApproved message.  If it received the second, it might take other action, such as sending an email to the customer.

You may have noticed that we just created a messaging protocol.  That is, the Order service must correlate multiple messages related to the same business process, and keep track of state related to those messages.  Within the Order service, the logic would be something like this:

• When an order is placed (in an inbound web request), save it, publish an OrderReceived message, and send the customer a response message that the order was successfully received.
• When an InventoryAssignedToOrder message is received, look up the order and record the assigned inventory quantity next to the quantity ordered.
• When inventory has been assigned for all quantities of all products in the order, publish an OrderApproved message.
• When an ItemOutOfStock message is received, send an email to the customer.
• When an hour passes after sending an OrderReceived message, if not all quantities in the order have been assigned inventory and no ItemOutOfStock message has been received, publish an OrderDelayed message.

This is a saga — a long-running process within a single service that requires the service to correlate messages and track state across those messages.  Note that this is just one side of the equation.  The Inventory service might have its own saga. 

Notice how each of the saga’s business rules start with “When”.  These rules are what make the architecture event-driven.  Notice also how simple the rules are.  Especially interesting is that the technical implementation maps almost directly to the business rules.  We would create an OrderProcessingSaga class, which has methods for Handle<OrderReceived>(), Handle<InventoryAssignedToOrder>(), etc.  The simple logic of each method is described in one of the bullets above.  (The final bullet is implemented in Handle<Timeout>().)

How would we accomplish the same process in a synchronous RPC (remote procedure call) architecture?  In RPC (like typical HTTP-based web services), a request is issued and the requestor waits for the response.

• When an order is placed (in an inbound web request), save it.  The inbound connection remains open.
• The Order service opens a new connection to the Inventory service.  The connection remains open while the Inventory service determines whether inventory is available for all the quantities in the order.  The response to the Order service includes data on any product SKUs that are out of stock.  The response is sent and the connection from Order service to Inventory service is closed.
• The Order service looks for any out of stock SKUs in the response.  Based on that, it creates the appropriate message (“order confirmed” or “items out of stock”), sends the customer a response message.

At first glance this might seem no different than the message-based process above.  But there are a number of problems with the RPC approach that reach across most of the -ilities:

Reliability.  Even with all the redundant hardware in the world, at some point the Inventory service will be down.  During that time, no orders can be accepted.  If each of the two services has 99% uptime, the total uptime for the system from the customer’s perspective is 99% x 99% = 98.01%.  The system as a whole is less reliable the least reliable component.  To get the system to 99% uptime, both services need uptime of at least 99.5%.  That means a greater investment in hardware, maintenance, etc.

In the message-based approach, the Order service can happily process orders without the Inventory service for up to an hour (or whatever rule is applied in the saga).  The services are not temporally coupled — they don’t always have to be running at the same time.  From the customer’s perspective, the uptime is 99%. 

The Inventory service can be taken down for maintenance.  Perhaps it could be deployed to two cheap servers instead of to an expensive active-passive cluster.  All without affecting the uptime of the Order service.

Performance.  In the RPC approach, the customer submits an order and then waits: while the Order service records the order, while the Order service contacts the Inventory service, while the Inventory service responds, and while the Order service figures out what message to return.  What if the Inventory service takes 5 seconds to determine whether inventory is available?  The customer sees a spinning ball.  In the message-based approach, the customer waits only for the Order service to record the order.  A response is them immediately sent to the customer. 

Now add the latency of communication between the services.  If they are in different data centers, that could add half a second to the customer’s wait time in the RPC approach.  It adds zero time in the message-based approach.

Scalability.  In the RPC approach, connections between the customer and the Order service remain open for longer (as described above).  Let’s say the Order service receives 10 orders/second.  If the connection remains open for 2 seconds, the Order service has to support 20 simultaneous connections.  If the message-based approach reduced the connection time to 1 second, the Order service only has to support 10 simultaneous connections — for the same volume of orders.  This disparity can become much worse under real-world traffic peaks.  Customer requests may wind up queuing (decreasing performance further) or even timing out.

The same problem occurs between the Order service and the Inventory service, as connections are consumed there in the same proportion.

Transparency.  Take another look at the logic for the RPC and message-based approaches.  In which one is the business logic more readily apparent?  Which one would do you think a sales rep would more easily understand?  I believe that the message-based approach wins handily on both counts.  As mentioned above, the business logic maps almost directly to the actual implementation classes and methods.  While a good RPC design can also have this quality, transparency is very natural and very easy in the message-based approach.

Maintainability.  Let’s add shipping to our business process.  In the RPC approach, during the order request, just after we assign the inventory to the order, we would open a connection to the Shipping service, ask it to ship the order, wait for its response, and then send the response to the customer.  With this third service, we’ve exacerbated all of the reliability, performance and scalability issues described above. 

All three systems have to be running.  At 99% uptime for each service, our overall our system is now down to 97.03% uptime.  We don’t want to ship the order unless we actually have all products in stock, so we have to wait for the request to the Inventory service to return before we talk to the Shipping service.  Our connections from the customer are now up to 3 seconds each, and our Order service has to support 30 simultaneous connections.

What happens when we’ve assigned inventory and then the call to the shipping service fails?  We have to free the inventory somehow, so we place the whole order request in a transaction.  That transaction flows across each service call, so that if shipping fails the inventory assignment is rolled back.  The transaction management adds half a second to the customer’s wait time, and we’re up to needing 35 simultaneous connections on our Order service.

In the message-based approach, we create a new saga within the Shipping service.  It has a rule saying: When an OrderApproved message is received, try to ship the order.  If successful, publish an OrderShipped message; otherwise publish an OrderFailed message.

We add rules to the OrderProcessingSaga:  When an OrderShipped message is received, update the order status; and when an OrderFailed message is received, update the order status and send an email to the customer. 

And we add a rule to the Inventory service’s saga:  When an OrderFailed message is received, release any inventory assigned to the order.

We haven’t had to make a single change to the processing logic for the customer’s initial request to place the order.  We haven’t had to create distributed transactions, because the business rules in the various sagas handle failures correctly.  We haven’t reduced our system uptime.  We haven’t lengthened the time a customer waits for a response, and therefore we don’t have to support more simultaneous connections from customers.

Conclusions

The business process described here is pretty simple.  Real world processes get much more complicated:  Add a credit check before assigning inventory.  Bill the customer after the order ships, after getting sales tax computation from an external service.  Substitute an equivalent product if the one ordered has been discontinued.  Yikes! 

If you read “service-oriented” as “synchronous RPC-style web services,” you’ll quickly be in big trouble with a system of any significant size.  However, if you read “service-oriented” as “event-driven, autonomous business services communicating with asynchronous message across service boundaries,” you’ll have a much better chance of actually enjoying the maintenance of your system.  I’ll take the latter, thanks.

These ideas come almost entirely from Udi Dahan and how he implemented nServiceBus, but unfortunately I can’t find where he said it.  It may have been when I attended his class in Austin last October.

I define configuration as “stuff that needs to be easy to change.”  Udi says there are two major categories of configuration, with very different characteristics.  One category has to do with operational concerns, such as:

• The specifics of the physical deployment environment (URLs, machine names, connection strings, etc.)
• Monitoring and troubleshooting (logging verbosity and where log entries are stored, etc.)
• Scaling out (how many app instances or threads should be running, etc.)

These are things that administrators care about deeply.  They want to be able to move things to different machines, spin up a new instance of your service, failover a database server, etc. And as a developer, you want them to be able to do all of those things without calling you.    These “administrator config” settings have no effect on the semantics of your application.  They change “physical” characteristics, not business-logical characteristics.

A second category of configuration does affect the semantics of your application.  Udi calls this “developer config.”  Changing it will have an effect on what the application does.  These are things like:

• Using a different implementation of a interface (e.g., a gateway that talks to a database vs a remote web service)
• Whether a particular operation requires a transaction (e.g., the WCF settings for a specific service)

Changes to these often need to be one-line-of-code simple, which makes them “configuration” in my mind.  But they also imply a requirement change because they change how the application works.  (Yes, adding or removing a transaction is a semantic change.)  Therefore you definitely don’t want administrators to go and change them on production servers.  The best way to prevent them from changing these settings it to give them no way to do it!

The most common objection to putting the developer config in code is that you have to redeploy your application.  Yep, exactly.  Changing developer config alters the semantics of your application.  Any such change should go through all of your testing and validation processes before being released.

Digging a little deeper, a lot of the resistance to putting developer config in code stems from fear of deployment.  If deployment is hard, error-prone, and stressful then you try to avoid it by putting as many things in your config file as possible.  (The same rationale is often given for putting business logic in stored procedures.)  If you cross your fingers every time you deploy, you’re doing it wrong. 

Deployments (and rollbacks) should be easy and reliable.  That means largely automated.  Once you have automated builds, lots of automated tests, and (mostly) automated deployment/rollback, “hard coded” is no longer a scary concept.  See this and this. JFHCI.

Ever opened up a config file that looked really scary?  How about a default WCF config with dozens and dozens of settings for a single service endpoint?  How many of those things do you really want someone to change on the production servers?  5% of them?  Once you’ve removed all of that developer config, the administrators will thank you for removing all that noise you told them to absolutely, positively never touch.  They’re also a lot less likely to catastrophically fat-finger a random character that will be lost in a sea of angle brackets.

In this post I’ll detail what happens during a request to the default ASP.NET MVC site that you get when you create a new MVC project in Visual Studio.  My goal is to list the major classes involved and how they interact.  There is a lot more that goes on during a request, and I’ve completely skipped action filters.  This is just the highlights.

First, there are some steps that happen at application start:

• The web.config file adds System.Web.Routing.UrlRoutingModule.  During initialization, UrlRoutingModule attaches event handlers for HttpApplication’s PostResolveRequestCache and PostMapRequestHandler events.  These handlers do some magic (using pre-existing extension points in ASP.NET) to ensure that requests in both IIS6 and IIS7, and for various versions of .NET, all wind up in the right place.
• The web.config file also adds MvcHttpHandler.  Requests matching *.mvc are handled with it.  This is also part of the goo that makes MVC work with different versions of IIS and .NET.
• Application_Start().  This HttpApplication event handler is overridden in the Global class (Global.asax.cs).  It calls the RegisterRoutes() method, also defined on the Global class.
  • RegisterRoutes() informs the routing infrastructure which requests to route to which controllers and actions, how to populate action method parameters from the URL, and what the default parameter values are.  It does this by adding Route objects to an ordered collection.

The application is now setup to begin accepting requests.  Here are pseudocode and descriptions for what happens on each request.  Note that wherever you see “httpContext”, the object is actually derived from the HttpContextBase class defined in System.Web.Abstractions.  This avoids the web forms dependency on HttpContext, and allows for code execution and testing outside the context of a web request.

This could use a sequence diagram, and I hope to create one soon.  In the meantime, you can try to follow along in Reflector (or the MVC source if you’ve downloaded it).

• The UrlRoutingModule event handlers do their magic, the result of which is the creation of an MvcHttpHandler object and a call to its ProcessRequest() method.  MvcHttpHandler derives from UrlRoutingHandler, which is part of the routing API and implements IHttpHandler.
• mvcHttpHandler.ProcessRequest():
  • routeData = RouteCollection.GetRouteData(httpContext);
    • In turn, calls route.GetRouteData() on each route in the collection. The collection is whatever we added during RegisterRoutes() at application startup, in order. The first route to return a non-null value wins the request.  RouteData contains the names of the controller and action (both required), along with the values of any other tokens defined in the route URL format.
      • RouteData is important, as it carries request-specific data (e.g., URL token values) that are not present in HttpContext.  The RequestContext object is an aggregation of HttpContext and RouteData, and is available to all later processing of the request.
  • mvcRouteHandler = routeData.RouteHandler; (MvcRouteHandler implements IRouteHandler, which is part of the routing API.  MvcRouteHandler is just a very thin adapter between routing and Mvc.)
  • mvcHandler = mvcRouteHandler.GetHttpHandler();
  • mvcHandler.ProcessRequest(httpContext);  (MvcHandler implements IHttpHandler.)
    • Gets the controller name from the RouteData.
    • Gets the singleton instance of DefaultControllerFactory.
    • controller = factory.CreateController(requestContext, controllerName);
    • controller.Execute(requestContext);
      • Creates a ControllerContext, which is just the RequestContext plus a reference to the controller instance.
      • Gets the action name from the RouteData.
      • Creates an ActionInvoker
      • actionInvoker.InvokeAction(controllerContext, actionName)
        • Maps values in the RouteData to parameters on the action method with matching names
        • If there are complex parameter types that can’t be directly mapped from RouteData values, the invoker instantiates an IModelBinder for each parameter and calls BindModel() on it to get the parameter value.
        • Invokes the action method with all the parameters.
          • In typical usage, action methods get data, add that data to the ViewData dictionary and/or the Model property. Then the action method calls the controller’s View() method.
          • controller.View() method:
            • Gives each registered view engine an opportunity to “claim” the view. The default WebFormViewEngine uses the virtual path to locate the view. The default virtual paths it checks are:
              • ~/views/{controller}/{action}.aspx and .ascx
              • ~/views/shared/{action}.aspx and .ascx
            • View() returns a ViewResult object (derived from ActionResult) containing a reference to the view engine and the virtual path to the view.
          • The action method typically returns the ViewResult it gets from View().
        • The invoker calls result.ExecuteResult():
          • When called on a ViewResult, this method asks the view to render itself:
          • view.Render(outputWriter)
            • Performs the rendering and writes the output directly to the outputWriter (which is the HTTP response stream).

Dependency injection is a hot topic these days.  You hear terms like “dependency injection”, “inversion of control”, “IoC container”, “DI container”, etc. a lot.  But like with “SOA”, people tend to define the terms however suits them.  I’m going to do the same.

The first thing I want to do is distinguish between dependency injection and a container.  Dependency injection is a pattern.  You don’t need any software tools other than your favorite language and compiler to “do dependency injection.”  The dependency injection pattern is a subcategory of the inversion of control (IoC) pattern.  A lot of people use DI and IoC interchangeably, and that’s fine with me, as DI is by far the most common type of IoC.

An container is a software tool.  Examples of .NET IoC/DI containers are Spring.NET, StructureMap, Castle Windsor, Autofac, and Unity (part of Enterprise Library).  While all of these have their own unique bits of functionality, they have a large overlap in that they are all container implementations.

An analogy: You’ve probably heard of the Repository design pattern for data access.  And you’ve probably heard of object-relational mapping (ORM) tools like NHibernate, LLBLGen Pro, Linq to SQL and Entity Framework.  The relationship between them is analogous to the relationship between the dependency injection design pattern and IoC container implementations:  If you’re using the design pattern, the tool makes life easier for you.  But it’s entirely possible to use the pattern without using the tool.

So what is the dependency injection design pattern?

Let’s start with the problem.  Most classes have to collaborate with other classes in order to fulfill their responsibilities.  But having one object instantiate another creates a hard dependency that can limit flexibility, testability, and transparency to consuming developers.

Let’s write some code for a big important Boss who asks her Gopher to go get lunch:

   1: public class PizzaService

   2: {

   3:     public string DeliverFood()

   4:     {

   5:         return "Large pepperoni.";

   6:     }

   7: }

   8:  

   9: public class Gopher

  10: {

  11:     public string GetLunch()

  12:     {

  13:         var pizzaService = new PizzaService();

  14:         return pizzaService.DeliverFood();

  15:     }

  16: }

  17:  

  18: public class Boss

  19: {

  20:     public void HaveLunch()

  21:     {

  22:         var gopher = new Gopher();

  23:         var myLunch = gopher.GetLunch();

  24:         this.Eat(myLunch);

  25:     }

  26:  

  27:     private void Eat(string food)

  28:     {

  29:     }

  30: }

One big problem with this code is that the only thing the Boss can ever have for lunch is pizza.  Another drawback to this code is that Gopher’s dependency on PizzaService is opaque and hidden.  The only way to know there is a dependency is to open up the code of the Gopher class and read it.  It doesn’t appear anywhere in the constructor or method signatures.  We want as much as possible to be obvious and explicit.  We don’t want developers using our APIs to have to sift through our code to figure out all the dependencies.

We can start to address the first concern by creating an ILunchService interface:

   1: public interface ILunchService

   2: {

   3:     string DeliverFood();

   4: }

   5:  

   6: public class PizzaService : ILunchService

   7: {

   8:     public string DeliverFood()

   9:     {

  10:         return "Large pepperoni.";

  11:     }

  12: }

  13:  

  14: public class Gopher

  15: {

  16:     private ILunchService lunchService;

  17:  

  18:     public Gopher()

  19:     {

  20:         lunchService = new PizzaService();

  21:     }

  22:  

  23:     public string GetLunchForTheBoss()

  24:     {

  25:         return lunchService.DeliverFood();

  26:     }

  27: }

But we still have the same problem of pizza every day, because the Gopher is still creating the instance of PizzaService.  Even if the Boss is a real pizza fanatic, we can’t unit test Gopher without actually having a pizza made and delivered.  That could get pretty expensive.

In more real-world terms, we can’t write tests without creating and accessing real instances of expensive resources (like a database).  That means the unit tests will be slow, and that’s very bad.  We want to run hundreds or thousands of unit tests in a few seconds.  Even with larger, slower integration tests we don’t actually want to have hundreds of pizzas delivered when our automated test suite runs every night…

And we also haven’t addressed the opaque dependency of Gopher on PizzaService.

So the next step is for the Gopher to require that somebody tell him what kind of lunch service to use.  (This isn’t the most proactive gopher in the company.)

   1: public class Gopher

   2: {

   3:     private ILunchService lunchService;

   4:  

   5:     public Gopher(ILunchService lunchService)

   6:     {

   7:         this.lunchService = lunchService;

   8:     }

   9:  

  10:     public string GetLunch()

  11:     {

  12:         return lunchService.DeliverFood();

  13:     }

  14: }

At this point, we are using the dependency injection pattern in the Gopher class.  Specifically, we are using constructor injection.  That is, in our constructor, we are asking for someone to pass in (inject) an instance that we depend on.  That’s all dependency injection is.  Big words, simple concept.  We’ve inverted the usual way things are done.  Gopher doesn’t control how its dependencies are created, the consumer of Gopher does.  “Inversion of control” is a fancy phrase for letting the consumer take control.

We could also have used property injection (setting a property value with the dependency) or method injection (passing the dependency as a parameter to a method).  But the best practice is to use constructor injection for required dependencies — don’t allow someone to create an object if it doesn’t have its required dependencies fulfilled — and property injection for optional dependencies.  Method injection is really only recommended when you’re adding a container implementation to an existing code base.  It’s yucky (because it’s less obvious), and shouldn’t typically be used in new code.

There are two big benefits to our use of the dependency injection pattern at this point:  First, the Boss can get any kind of lunch she wants by simply telling the Gopher what kind of service to use.  And second, other developers who want to use the Gopher class can’t help but see that the Gopher depends on an ILunchService — you just can’t create a Gopher instance without one.  This is the kind of explicit, obvious dependency we want.

But we still have a problem.  We’ve made a pretty career-limiting move for the Gopher.  We gave the Boss more work to do.  The Boss now has to create the PizzaService in order to get lunch:

   1: public class Boss

   2: {

   3:     public void HaveLunch()

   4:     {

   5:         var pizzaService = new PizzaService();

   6:         var gopher = new Gopher(pizzaService);

   7:         var myLunch = gopher.GetLunch();

   8:         this.Eat(myLunch);

   9:     }

  10:  

  11:     private void Eat(string food)

  12:     {

  13:     }

  14: }

You might say “That’s only one more line of code than the Boss had before.”  Well, I’ve found that giving Bosses (or developers using your API) even a tiny bit more work to do is generally a bad idea.  And while we’re on the subject, why should the Boss have to create the Gopher, too?  The Gopher should just be there, ready to do the Boss’s bidding.  In fact, isn’t the Boss dependent on the Gopher?

Oh, wait a minute, we already know what to do with hard dependencies caused by using the new operator — we use dependency injection:

   1: public class Boss

   2: {

   3:     private Gopher gopher;

   4:  

   5:     public Boss(Gopher gopher)

   6:     {

   7:         this.gopher = gopher;

   8:     }

   9:  

  10:     public void HaveLunch()

  11:     {

  12:         var myLunch = gopher.GetLunch();

  13:         this.Eat(myLunch);

  14:     }

  15:  

  16:     private void Eat(string food)

  17:     {

  18:     }

  19: }

We’ve applied the dependency injection pattern to the Boss, too, and another dependency (of Boss on Gopher) has been dragged into the light of day for all to see.  In this case we haven’t created an IGopher interface, but that’s okay.  Sometimes you don’t need to use an interface (although often you should).  With or without an interface, developers using the Boss class now have a much clearer picture of what’s going on — without digging into the actual code.  Everything is explicit and obvious.

You might start to wonder whether some objects that do a lot of things are going to have 10 constructor parameters.  Well, yes.  But that’s a code smell: if you have an object with that many dependencies, it’s probably doing too much.  It’s very likely that it has multiple responsibilities, and your classes should typically adhere to the Single Responsibility Principle as much as possible.  Split that class into several that each does one thing only.  This makes your software easier to change, too.  Smaller, simpler classes mean each class has fewer reasons to change, and fewer collaborators means fewer potential ripple effects when you do make changes.

Here’s one of the big ideas behind dependency injection:  separating the object graph from the execution graph.  In code where you see new Foo() all over the place, the object graph and the execution graph are tightly intertwined.  That’s usually a bad thing, because objects rarely reference each other in the exactly the same hierarchical structure that they call each other’s methods.  Testing or changing a little thing in that kind of code can be a real pain.

A common solution for separating object graph creation from the execution graph is to use factory classes.  The Abstract Factory pattern is one of the older and better known design patterns.  All of the instantiation and injection of the dependencies would happen in the factories, out of the way of your executing business logic.

   1: public static class BossFactory

   2: {

   3:     public static Boss GetBoss()

   4:     {

   5:         return new Boss(new Gopher(new PizzaService()));

   6:     }

   7: }

In this code, the boss is still having pizza every day for lunch, but it’s easy to imagine how we could use configuration or a UI input value to select a different implementation of ILunchService each day.  The key is that the selection of that implementation doesn’t really have anything to do with the process of actually having lunch.  And now our code separates those two processes very cleanly.

Further reading on dependency injection:

• Dependency Injection Demystified by James Shore
• Dependency injection on wikipedia
• Misko Hevery’s blog, especially
  • Talk on dependency injection
  • How to Think About the “new” Operator
  • Singletons are Pathological Liars
  • Guide: Writing Testable Code

At the time I thought the idea was a little hare-brained.  It had occurred to me while I was brushing my teeth one morning and it seemed interesting enough.  I felt a little bit less hare-brained when Scott Hanselman posted in September about his discovery of Silverlight living outside the browser in several ways, most notably the Mesh Operating Environment.

I’m pretty sure that MOE is the same thing as the Live Operating Environment that is part of the Live Framework.  In effect, the LOE is a mini-CLR — just like Silverlight is.  LOE lives either on a device (computer, phone, etc.) or on the Live Mesh servers.  In both cases it provides a stripped down CLR with extra security.  (I know this is an oversimplification, but I think it is generally correct.)

I feel even less crazy now that Rocky Lhotka has posted Some thoughts on Windows Azure and a follow up.  (The marchitecture diagram on the Windows Azure site shows Live Services — which contains the LOE — as just one component that runs on top of Azure.  I’m conflating the LOE and Azure, but I don’t think that affects the point.)  Rocky says of Azure:

Remember that we’re talking about a restricted runtime, with a restricted architecture and API. Basically a controlled subset of .NET. We’re already seeing this work – in the form of Silverlight.

And later:

So what we need, I think, is this server equivalent to Silverlight. Azure is not that – not today – but I think it may start us down that path, and that’d be cool!

Scott and Rocky go much further than I did, and are certainly better writers.  But with those two seeing the same coolness I do in the idea, I have much less reason to question my sanity.