Find a post...

DNN-Connect Blogs

The Future of DNN Speaks Razor - #4 The Death of ASP.net MVC

You may have ready my article on the death of ASP.net WebForms. In summary we can say that WebForms is becoming obsolete, because Microsofts vision of hiding the web-complexities from the developer and giving her a Visual-Basic style programming environment failed.

Along came MVC to provide a new solution. And there are quite a few things it's done very, very well. And a lot of things that won't make it. Our goal is to focus our time and energy on the relevant parts and ignore the rest.

In this part 4 of my Series The Future of DNN Speaks Razor, I'll explain why ASP.net MVC started well but was overtaken by the internet, and why the resulting good solution is still called MVC, even though it's not Model-View-Controller.

ASP.net MVC is Dead…

ASP.net MVC completely turned around Microsofts Visual-Basic-style approach to the web: This time, it was "embrace the web" and leverage what it does. Suddenly it was all about testability, patterns, Dependency-Injection, Inversion-Of-Control, Routing, Dynamic Objects and more. And it was a very tough start.

It looked great on paper - the same way a business plan looks great on paper. And in practice it also felt like a business plan - academic and unrealistic. The technology and solution was just too trivial to produce great solutions. A classic problem was that you suddenly had loads of tiny fragments of a solution to manage. And getting these to work together felt simple - as long as your solutions were at demo-level and trivial. Suddenly the platform didn't do much anymore, and many things it did (like adaptive views for mobile devices - see my post on Responsive vs. Adaptive) were ivory-tower leftovers and not really relevant.

The start was so tough that for many years, third-party controls simply sucked. Getting something like a WYSIWYG control (like the classic telerik rad-editor) in MVC was like picking up your kids bike to replace your car. It may feel like you're going green, but you're not going anywhere!

To the left you see the amazing MVC-Telerik editor - and it's easy to see that the non-MVC-edition to the right was a bit better at the time...

Third party controls finally got better - when they started doing everything in JavaScript. That's right: they got better, when they stopped relying on ASP.net MVC. This became obvious when the control makers (incl. Telerik) started marketing their controls to also work with Java and PHP. Of course they work - they are simply HTML, CSS and JS!

Here the newest non-WebForms editor. Better (because zero-ASP.net) but still not even close to the WebForms version. 

…because MVC is Now Happening on the Client, not on the Server…

Think about the "cool" UIs you see today, like a powerful mail client (Google, Outlook), a neat game, a stylish business UI. All of them have in common, that the entire View is client rendered using AngularJS, knockout or Kendo.

 

the two most popular MVC-style frameworks in JS at the moment

Today's SPA (Single Page Application) receives a generic HTML, a generic JavaScript and a generic CSS. I'm saying generic because these pieces don't vary with URL parameters or with user logins. When the server was in charge, each request delivered a different HTML, usually containing the tables, the data, fragments of the JS and more. This is passé.

But when the server doesn't have to deliver different content-fragments based on URL or session state, what good is programming on the server? Why play MVC on the server if you already do it on the client? The simple answer is: you don't. The need for MVC on the server is collapsing…at least for Apps (content-management is another story). 

You won't Notice MVC on the Server Failed, Because they Rethinged the Name

That's right! Some things get renamed, but MVC got re-thinged. I guess Microsoft realized that another name would further confuse everybody - and anger all the early adopters who already had a hard time getting into MVC. Imagine telling them "Yeah, it was hard, and it sucked, and it was unproductive - but in the long run, we don't need it any more." That's a recipe for losing developers. So Microsoft opted for the "MVC got much better, it now also does lots of new things that don't have to do with MVC. You can also use this now!"

Examples of how the Name MVC got Re-Thinged

Most of the really important new features in ASP.net (and supposedly part of MVC) have little or nothing to do with Model-View-Controller Separations-Of-Concerns in the view-layer of an application. Here some examples: 

  • ASP.net WebAPI part of MVC 4 - a data layer if ever I saw one, ideal for JavaScript applications
  • Razor - a text-parser if I may say so - was heavily marketed as part of MVC 4
  • SignalR 2 (http://www.asp.net/signalr) part of MVC 5 - real-time communication, ideal for JavaScript applications

Other features like Routing etc. are awesome but they are basically necessary for any kind of web site incl. WebForms and CMSs in general (irrelevant of the framework-flavor below).

But to keep things simple MS choose to keep the name MVC. It'll get more complicated when they start promoting Katana etc., but for now they call new things MVC. I believe this will change in 2015...

The Browser is the better MVC-Playground

I would like to add a note on a common misconception: MVC is a View-Layer Pattern. I've met many programmers who try to place the business and data-layer in the "M" or "C" layer of MVC (model or controller). Both are completely and utterly wrong - M,V, and C are not the tiers 1,2 and 3 of an n-tier-solution. MVC is a way to split the view-layer (the top layer of the n-tier solution) into 3 Separations-of-Concerns. You still need a business and a data layer in an MVC-App. 

Doing M, V & C in the browser is much easier because the three parts are connected, live and receive mouse-interactions. Doing this on the server was just frustrating, difficult and totally unsexy for the end user.

In Summary MVC is dead on the Server…

So the basic MVC-concept, replacing the VB-Style Page/View separation with a Model-View-Controller-Style separation on the server is history. Todays and future web applications will embrace MVC / MVVM / MVP - but they will do it on the client. ASP.net will be an important layer in the application stack, but not because of MVC.

Not all is Lost…

Because the server still serves an important role in many other sub-function, incl. Data-Delivery. That's where Microsoft built a masterpiece with the WebAPI. More on that tomorrow…

With love from Switzerland
Daniel

Daniel Mettler grew up in the jungles of Indonesia and is founder and CEO of 2sic internet solutions in Switzerland and Liechtenstein, an 20-head web specialist with over 600 DNN projects since 1999. He is also chief architect of 2sxc (2SexyContent - see forge), an open source module for creating attractive content and DNN Apps.

 

PS: Want to get started before the entire Razor-series is out? For the impatient, try the DNN-Razor Host Module and watch this video  or try packaged code apps by installing 2sxc and some of the Razor Apps like the Razor Basic TutorialsList-Tutorials or the SQL and Peta-Poco Tutorials

 

Daniel Mettler learned programming with the bible translation computer of his parents, deep in the jungles of Indonesia. Since he was only 12 years old at that time and the BIOS only had a version of BASICA, that's what got him started. With 16 he went back to Switzerland and learned German and basic city-survival skills. Equipped with this know-how he founded 2sic internet solutions in 1999 which was focused on web solutions on the Microsoft platform. After a few self-developed CMSs 2sic switched to DNN in 2003 and has been one of the largest partners (17 employees, 700+ projects) in Europe. Daniel is also the chief architect behind the open source 2sxc, a strong promoter of standardization (boostrap, patterns, AngularJS, checklists, etc.) and loves to eat anything - dead or alive. His motto: if the natives eat it, it game.
Comment(s)
Peter Donker
Peter Donker  Next thing you're going to tell us is that Elvis is dead, too.
· reply · 0 0 0
Manfred
  Daniel, thanks for the perceptive study. Please continue your instructive blog work.
· reply · 0 0 0
Brian Lacy
  You're right that modern web apps operate primarily on the client side. With WebForms, that's not possible. ASP.NET MVC gives control back to the developer. As a result, modern, thick-client web apps actually work well with ASP.NET MVC. Of course, the other bit you're right about is Web API. This framework leaves the interface -- the View, if you will -- entirely up to the to developer. But that's the polar opposite of WebForms, so it doesn't make much sense to extoll the virtues of both WebForms and Web API while condemning ASP.NET MVC as "dead". Incidentally, the following is one of thousands of examples of why you are quite wrong about ASP.NET MVC being "dead" -- in fact it's very much alive! http://www.google.com/trends/explore#q=asp.net%20mvc%2C%20webforms%2C%20asp.net%20web%20api&cmpt=q
· reply · 0 0 0
Daniel Mettler
Daniel Mettler  Thanks for your comment! Just in case you missed the previous blog: WebForms is very dead too - there is no confusing that. I did not plan to promise anything for webforms, we don't like it anymore either :) And regarding asp.net mvc being alive - yes, people are actually using it - but comparing it to other alternatives like AngularJS (which would make MVC more or less obselete) shows a clear trend to the alternative: http://www.google.com/trends/explore#q=angularjs%2C%20asp.net%20mvc&cmpt=q
· reply · 0 0 0
Chris Niedbala
  "M,V, and C are not the tiers 1,2 and 3 of an n-tier-solution." I've come from a WebForms/WinForms (stateful) background using 3-tiers (UI + business object tier and data access tier). I have been trying to understand MVC/MVP/MVVM and it is helpful for me to remember that these layers are all UI layers and not your typical 3-tiers. However I suppose I have typically thought of the Model layer as being somewhat more in the business (domain) layer than the UI layer. To put this another way, the Model, in my mind, has reflected the database more than it has each UI view. I was under the impression that MVVM solved this by giving each View its own ViewModel that reflected the UI View (as a model) which was separate from the Model itself (which reflected the domain/database). So my question is this... if all of these MVC layers (or MVVM, MVP) are truly UI layers (which still have business and data layers beneath them) what is the distinction of having a Model and a ViewModel all in the UI layer?
· reply · 0 0 0
Daniel Mettler
Daniel Mettler  MVC: Basically all these MV* solutions all try to solve the UI layer. But many don't get that, so you will find many examples that show horrible implementations. There are probably more bad examples out there than correct ones - again proving that technology doesn't solve problems :). So regarding the wording Model or ViewModel: I'm sure you'll find people that will give you a clear distinction (and then add that their version is better). I can't give you that - simply because I'm sure there is no consensus on this. So I wouldn't bother too much. Just remember that the model is neither the Busines-Layer nor the Data-Access-Layer. These should be separate. And then work with a thing which contains data for the view - and call it Model or ViewModel - whichever you prefer. I prefer ViewModel because it helps the listener realize what I really mean. Best, Daniel
· reply · 0 0 0
Simon
  Webforms is supported in vs2013 and onwards. You may think it's dead, MS seem to have other ideas. How can you speak of their behalf?
· reply · 0 0 0
Colin
  Yep it's dead
· reply · 0 0 0

Hosting liberally provided by

Philipp Becker 6010 7
Geoff Barlow 542 4
DNN-Connect 431 6
Peter Donker 5079 30
Christopher Hammond 683 2
Olivier Jooris 418 1
Daniel Mettler 12040 88
Clint Patterson 1 1
Jos Richters 65 1
James Rosewell 327 2
Will Strohl 1548 27
Ernst Peter Tamminga 438 4
Barry Waluszko 2794 2
Declan Ward 452 1
Gifford Watkins 722 9
Torsten Weggen 2755 3