Andrew Siemer's Blog

Enterprise Web Applications, ASP.NET MVC, C#, SQL Server, Architecture, & Writing
posts - 62 , comments - 145 , trackbacks - 0

Building Distributed Applications in ASP.NET MVC at MvcConf 2010 on 7/22/2010

Next week Thursday I will be speaking at MvcConf.  This is a virtual, free conference that has attracted some very heavy hitters MVC hitters to come and chat about their voodoo.  This should be interest sting.

Below is the abstract and TOC for my presentation.  If you think I missed something or am watering down the presentation please feel free to contact me to give me your suggestions.


In this session we will take a look at a handful of common ways that MVC applications are created along with each approaches pros and cons. We will start with a very simplistic, not so flexible, ecommerce application. This will then be followed by several iterations of refactoring to embrace different design patterns, easier code management, loose coupling, better testability, more flexible deployment options, etc. Our final iteration will put us in a place where we can easily scale the system to include the ability to plug in a distribution layer for remote processing with a little IoC and MVC.

We will start by looking at the traditional demo style application where business logic, data access, and everything in between is handled in a controller – not much different than the bloated code behind of WebForms days. Then we will take a look at how to slowly refactor that type of application into something better. We will take a look at how to move towards the single responsibility principle. Next we will take a look at moving to logical separation of our code using namespaces (creating layers). Then we will move towards physical separation with different class library projects (creating tiers). Once our code is pushed into appropriate buckets we will look at removing tight coupling by implementing dependency injection. Then will be ready to plug in an IoC container (StructureMap in this case) which will allow us to easily swap out our concrete implementation as requirements change with little ripple affect felt by our application. At this point our application will be ready to easily support distributed processing on an as needed basis.

The map from start to finish

  1. Standard MVC demo application
    1. All code in a controller/action, or the view
      1. Domain model
      2. Business logic
      3. Data access (LINQ to SQL)
    2. b. Why is this bad?
      1. Causes code duplication and increased complexity
      2. Tight coupling results in less flexible code
      3. No abstractions and/or leaky abstractions cause unforeseen ripple effects
      4. Not easily testable
      5. Refactoring is more difficult
      6. Deployment options are fairly fixed
      7. Versioning specific parts of the application is not easy
      8. Not compose-able
      9. Not easily distributable
  2. Separating our concerns
    1. Putting code into small singularly focused classes
    2. Why is this better?
      1. More testable
      2. Easier to manage
      3. More reusable
      4. Refactoring gets better
  3. Logical separation (layers)
    1. Moving classes to appropriate namespaces
    2. Why is this better?
      1. Easier to manage
      2. A required step to getting closer to tiers
  4. Physical separation (tiers)
    1. Moving classes into appropriate physical assemblies
    2. Why is this better?
      1. Deployment options become more flexible
  5. Refactoring for dependency injection
    1. Achieving loose coupling with interfaces and constructor injection
    2. Why is this better
      1. Loosely coupled
      2. More compose-able
      3. Easiest to test
  6. Using an IoC container for flexible composition
    1. Implementing an inversion of control (IoC) container – StructureMap
    2. Why is this better?
      1. Dynamically compose-able.
      2. Ultimate flexibility for the developer
      3. Easy to seamlessly slip in new functionality
      4. Capable of supporting distributed processing
  7. Adding a WCF service client and services to support seamless application distribution
    1. Why is this better?
      1. Ability to distribute specific pieces of our applications to other servers
      2. Supporting horizontal scalability gets easier
      3. Vertical scalability can be applied to areas of your application rather than being forced to beef up the entire application

Print | posted on Thursday, July 15, 2010 8:27 PM |



# re: Building Distributed Applications in ASP.NET MVC at MvcConf 2010 on 7/22/2010

Hi, loved the presentation. I was the guy that asked the questions about security and service bus.

As mentioned, I am building something with a similar architecture as the one presented. I am worried about the number of requests to main entry point. I think this is where vertical scalability kicks in but do you have any other suggestions?
7/27/2010 11:25 PM | Daniel Merino

# re: Building Distributed Applications in ASP.NET MVC at MvcConf 2010 on 7/22/2010

What do you mean about main entry point? In this application architecture the whole idea behind how it is able to scale is that there isn't one main entry point. You can put your web site into a farm of servers. You can then take segments of your application and put each high volume segment into its own farm of servers. You can scale horizontally till your hearts content! Let me know what you mean specifically and I will try to address it.
8/11/2010 12:53 PM | Andrew Siemer

# re: Building Distributed Applications in ASP.NET MVC at MvcConf 2010 on 7/22/2010

How can we get the code showed during Presentation?
2/15/2011 4:25 PM | Ayub Patel

# re: Building Distributed Applications in ASP.NET MVC at MvcConf 2010 on 7/22/2010

Hi, any possibilities of getting the code you have used for this talk?
2/23/2011 7:03 PM | Shariful Islam

# re: Building Distributed Applications in ASP.NET MVC at MvcConf 2010 on 7/22/2010

Here are the videos from the conference on tekpub:

Here is the source and resources for the conference on codeplex:
2/24/2011 10:34 AM | Andrew Siemer
Post A Comment

Powered by: