Super charge your ASP.NET MVC website with ServiceStack's MVC PowerPack!

ASP.NET MVC is a fine web framework but ships with some inefficient and ugly parts by default and misses others, vital in this Internet age!
So like a .NET Santa, ServiceStack is in town to fill in gaps with goodies - because even good frameworks need love too :)
ServiceStack MVC PowerPack!

TL;DR - ServiceStack boosts your MVC website and is a dead-easy install with:

PM> Install-Package ServiceStack.Host.Mvc

The ugly side of ASP.NET MVC

ServiceStack is coming to town! (bearing gifts :)

Even if you don't intend to use its Web Services framework, you can still take advantage of ServiceStack's highly-optimized, testable components enabling better code-practices and faster response times!

IOC - Funq

json Although MVC was developed emphasizing separation of concerns and writing testable maintainable code it fails the final hurdle by not including an IOC - i.e. the most important ingredient influencing the creation of testable, loosely-coupled and maintainable code.

Without an IOC you're led to using test-inhibiting static variables whilst the composition of your app dependencies is relegated down to its in-flexible XML Config.
Only the configurable parts of your application should be in your Web.config as code remains the superior way to define and compose your apps dependencies and has the advantages of being debuggable and statically verifiable at compile-time.

Already well known to SOLID developers, an IOC promotes well-designed architecture yet it only takes a little IOC to reap its great rewards.
As it makes a great first IOC, we've included @kzu's Funq because of its tiny size, excellent perf and memory characteristics that sports an intuitive, friendly, code-centric interface.

To use: register all your dependencies in the new AppHost which are then automatically wired to the public properties or constructor of your MVC Controllers or ServiceStack web services. If you're already playing for team IOC, you likely have your preferred IOC player which you can draft pick instead from this wiki page.

A great resource if you're new to IOC/DI and TDD is Daniel Cazzulino ScreenCast series showing how he developed Funq using TDD.


json In the age of Ajax, instant utility and response times reigning supreme experiences, we're still not sure what led the MVC team to bundle .NET's most inefficient (and previously deprecated) JSON Serializer in JavaScriptSerializer. The lack of a JSON serializer with decent performance in .NET has some developers resorting to ugly hacks and has caused us to develop our own JSON serializer (also included) replacing .NET's slowest serializer with .NET's fastest - for multiple of times better JSON performance!
We feel the CPU heat energy savings could be put to better use, like toasting marshmallows over a warm xmas fire :)

As JSON is quickly becoming the worlds most important wire format, many websites have already changed their MVC websites to use ServiceStack's JsonSerializer including .NET's own MVC champion -

To easily use ServiceStack's new Cache, Session & JSON Serializer have your Controllers inherit ServiceStackController.cs or PageBase.cs (ASP.NET)

Escaping XML config jail

web.config .NET's config model was conceived during the great hype of XML, a time where XML was the most sought buzzword prompting most enterprise-serving-companies to wedge it in their products' stockings or find some other way to be word-associated with it. Yet when the hype dies down, value proposition is the only thing to keep it standing, and against well-designed code - it's found wanting.
It's consistently more verbose, a poorer object model fit, creating more friction in a less capable language that only becomes further compounded when it needs to be duplicated to run in different host projects e.g. test projects.

Unfortunately like most legacy tech the only way to be free of it, is to have a clean-break. There will never be a perfect lib implementation sufficing all use-cases, out-lasting the test of time. In order to avoid needing rewrites to take advantage of shinier tech, we prepare for it, in the cleanest way possible, by binding to interfaces not implementations - and the best way to package these interfaces is in a implementation / dependency-free dll.

And like all our good advice, we like adhering to it :) where all ServiceStack providers detailed below implement clean, unimpeded interfaces contained in the implementation-free ServiceStack.Interfaces Project.



Probably the most important facet in high-performance websites is Caching, which we feel should be a first-class concept, decoupled from the framework and made available like every other dependency so it remains testable, swappable and configurable allowing fine-grained control and a multi-tude of caching patterns inside your domain logic.

With this goal ServiceStack's Caching API includes a rich set of functionality and providers:


If your pages are enchanced with Ajax you can quickly run into ASP.NET's flawed Session design where any write access to the Users Session is locked for the entire request. Common symptoms of this limitation include degraded response times for your pages and ajax requests.

Not being strong fans of un-intended, debilitating magic behaviour, we provide our own simple yet flexible ISession API that takes advantage of our Caching API so User Sessions can be stored in any of the above Caching Providers.

The same ISession is available to both MVC Controllers and ServiceStack's Web Services that share the same Cookie Id allowing you to freely share data between these 2 web frameworks.


Even in the spirit of bind to interfaces, not implemenations, many .NET projects still have a hard dependency to their logging implementation. We still don't think it's a good idea so we provide an abstract logging framework with Elmah, Log4Net, NLog, EventLog, Console, Debug and Null logging adapters available.

Configuration AppSettings

Despite being avid protesters in the anti-XML config movement, we're still 100% for app Config in general though it should be limited to what's actually configurable by your application. Instead of building tiered configSection manatees we prefer to store structured data in Web.config's appSetting's values which is still able to express rich config graphs but does so in a much more human-friendly and manageable size.

To this end we provide our own pluggable AppSettings to provide high-level utility methods to read your Web.config's <appSetting/> values into a List, Dictionary or your own Custom Type using the human friendly JSV format.

Benefits over existing Configuration API include the ability to store rich data stuctures in appSettings values, more succinct access to typed data and since its an interface it can easily be swapped to source your configuration from an different source (e.g. from a central DB) without a rewrite.
Here's a quick example show-casing its use:

	<add key="LastUpdated" value="01/01/2012 12:00:00" />
	<add key="AllowedUsers" value="Tom,Mick,Harry" />
	<add key="RedisConfig" value="{Host:localhost,Port:6379,Database:1,Timeout:10000}" />
IResourceManager appSettings = new AppSettings();
DateTime lastUpdate = appSettings.Get<DateTime>("LastUpdated");
IList<string> allowedUsers = appSettings.GetList("AllowedUsers");
var redisConf = appSettings.Get<RedisConfig>("RedisConf");
var searchUrl = appSettings.Get("SearchUrl", ""); //use default value if no config exists

The default value is particularly nice as you can have workable default options in code whilst its overridable in the Web.config when you need to.

The Entity Framework problem

web.config If you're not concerned about poor performance or being surprised by the occaisional unintended behaviour, then there's a lot to like in Entity Framework :) Although there may be times when you want to improve a critical hotspot in your code or wish to escape EF's abstractions and flex your SQL skills by issuing optimized and complex SQL queries. For these situations you can make use of any of the included 2 fastest Micro ORMs in .NET in Dapper and OrmLite. Both ORMs work the same way in that they're simply Extension methods hanging off ADO.NET's System.Data.* interfaces. Since they don't require any config to setup, can make use your existing dbConnection and maps to clean POCOs - they are an easy and non-invasive option to use.

The best way to optimize pages with heavy database access is to profile it, and an easy way to do that is to make use of the Mvc MiniProfiler embedded in ServiceStack. The profiler has special support for profiling Entity Framework, Linq2Sql, Dapper and OrmLite. There's screenshots and a good overview of how to enable it in the v3.09 Release Notes.

ServiceStack REST Web Services

/api By now you should have a fairly good idea of the different libraries that make up the ServiceStack Framework and the core philosophy behind them promoting clean, simple, performance-focused solutions around good coding practices. The Web Service Framework itself closely follows this thread and extends it further by also promoting established remote service practices - uncommon in the .NET world. To get a flavour of its simple API, a basic Web Service and REST Service are included in this NuGet package and hosted from /api. Here's a recent thread describing ServiceStack's DTO-first advantages vs WCF's RPC paradigm.

In a CoffeeTable overview: ServiceStack is a high-performance, cross-platform web service framework encouraging established remote services best practices (i.e. Martin Fowlers Remote Facade, DTO, Gateway) common in the Java world and improved upon in ServiceStack after taking advantage of C#'s language features yielding a succinct and expressive framework that's also a friendly option for F# (on Win or Mono).

ServiceStack has strong support for all web formats where all services created automatically enable JSON, XML, HTML, CSV, JSV, SOAP 1.1/1.2 wire formats incl. HTML ContentTypes (form-urlencoded/multipart) and calling conventions (JSONP) out-of-the-box with no XML config required :). Whilst it only takes a single LOC to disable system-wide features.

For developer productivity viewing your web service in a browser returns a HTML5 JSON Report where its response can be introspected at a glance and a built-in Mini Profiler to easily able you to audit your web services execution times.

It's code-first DTO approach renders the API nearly invisible (i.e. the best kind :), getting out of your way to provide a friction-free dev experience where services are defined using typed, code-first DTOs making it a cinch to create coarse-grained APIs (best practice for remote communications). By default services bind to a DI/DDD clean room where it need only implement the dependency-free IService that accepts your C# Request POCO and lets you return any C# object, generating the desired output. C# Exceptions are handled as well, serialized into your Response DTO and sent with the preferred HTTP Status Code. It's layered design enforces loosely-coupled and testable code where the same unit test can run as an Integration test on all JSON, XML, JSV and SOAP endpoints.

For client/server connectivity, succinct and strong-typed Sync and Async generic service clients are included enabling typed access end-to-end without any code-gen (re-using code-first DTOs) on .NET/Mono platforms including MonoTouch. Whilst it works cleanly with popular Ajax libraries like jQuery and Backbone.js without requiring any bloated special-purpose libs to call your services.

And lots more...

utils In addition to the above, ServiceStack includes many other little nuggets to ease your development burden and help in achieving your next online masterpiece! Many utils are stored in Extension methods that are naturally discoverable during your day-to-day VS.NET travels. Here are some of the more notable features:

Where to next...

Follow @ServiceStack for updates. Read the documentation. Ask questions on StackOverflow (with the ServiceStack tag) or by posting to ServiceStack's mailing list.
For real-time support (that you just can't buy :) we're usually hanging out in