Last one out of the Kinjaverse, turn out the lights.
Last one out of the Kinjaverse, turn out the lights.
Illustration for article titled Goodbye MVC, Hello Web API

Three short years ago Microsoft released MVC version 1 for the .NET platform. This was a revolutionary step in the right direction to get away from web forms and to a better web development paradigm. Now consider the modern web application, tons of JavaScript, JQuery, JQuery-UI, Ajax, Backbone (or your JavaScript model framework of choice), and JavaScript template frameworks like Mustache. MVC gave us a way to quickly grab views through Ajax, toss the HTML into the DOM, and the wire-up the JavaScript events. Pretty cool right? Well, it was for the first year or two anyway.


The problem quickly became needing 2-way binding hacks to suck in the information from the newly generated partial view returned from MVC and generate a model that can then be altered and shipped back to MVC via Ajax upon some asynchronous operation. Yes there always was @Ajax.* which had binding into Microsoft's magical framework but it never failed that you had to hack things together to get anything complex to work.

Contemplate JQuery and $.ajax({...}) or $.post or $.get... Why in the world were we so eager to do all this additional work? Frameworks like Knockout or Angular were terrific at bloating the DOM to auto-magically do this work for you, but I thought we ditched web form's magic of runat="server" and OnClick="SomeLameServerMethod" for a better paradigm. We quickly replaced it with ng-click and more magic of behind the scenes auto-wiring and immediately destroyed the nice separation of concerns that we had achieved through MVC in the first place.

The market was starving for a paradigm to do modern web better. C# was a terrific language that has been growing geometrically in the market due to its controlled central access nature and ease of use BUT it's web offering was still leaving us wanting more. Enter WebAPI Controllers. We use JSon everywhere in our web applications, pulling it from form fields, doing magic with JavaScript and presenting a true "Smart Client" experience. Why in the world were we using these partial views and then hacking together JavaScript to pull the much needed model information from the DOM? This seems backwards right? WebAPI exposes a channel to talk only in JSon. I know prior we had JsonResult and return Json(new {....}, JSonRequestBehavior.AllowGet); but this was not the "preferred" method used and taught by MVC prior to the latest release. MVC4 and WebAPI Controllers gives you a controller to perform the actions you want all through JSon bindings and HTTP get / post / put.

How did this change anything do you ask? The answer is you use Backbone to capture the response from the server. Use Mustache to generate the HTML from the corresponding template and render the DOM! Bind to the events you want to control (some simple 2-way binding is available for Backbone, one for example is Rivet). The events are controlled through Backbone and sent directly back using only JSon to the server. Your DOM remains fairly unbloated, your client side logic is separated from your views, and your server logic for persistence is all segregated from view concerns.

Now I know many top notch web developers out there spent a great deal of time ramping their teams up to use MVC. Before you start thinking "Not another new technology to teach everyone".... The beauty of this is it is all technology you are using now and it is still part of the MVC Framework! Instead of dancing around boundaries created by the MVC partial view ajax paradigm, just cut straight to the end goal.... A rich client experience where the power is all in your JavaScript.

I encourage everyone to go and play with this paradigm and see how much more efficiency you can gain. Agility in technology will always yield a better and more maintainable end product. Always keep pushing the boundaries and never stop learning!

Share This Story

Get our newsletter