Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master
Demis Bellot mythz
62 lines (38 sloc) 16.577 kb

History of Microsoft and the Web – From ASP, ASP.NET to MVC

I was asked to provide some initial feedback of my impressions of ASP.NET MVC and since its been a while since my last post I thought it was as good as subject as any to start off my summer rants.

My background and personal recommendations

I would like to add that the contents contained here-in is from a web developers perspective (i.e. my own) having spent several years in the earlier part of my career building web solutions (which are still in production use today) with ASP, PHP and Java web frameworks and having felt the pain points and advantages of each first hand. Basically, I talk-of where I’ve walked.

I am currently an active developer of websites developed with both ASP.NET and ASP.NET MVC web frameworks which I continue to advocate for under different circumstances that yield the most benefits of each. Outside of work I also develop some websites with the Python Django web framework thanks largely to the free hosting that provided for by Google App Engine. If you are primarily a *NIX developer and performance is not your primary concern then the increasingly popular and productive Ruby on Rails web framework may be your best choice.

My personal love for the performance, productivity and elegance of the C# programming language has kept me tied to the .NET web frameworks. Although it really depends on your situation because I also think Google has ‘got it right’ where the best performance and User Experience may possibly be achieved by using no server-side web framework at all – instead relying on static html/css/js to run the entire web application inside the browser, calling on JSON/JavaScript data services for its interactive content. If you are curious with Google’s approach I recommend taking a look at the Google Closure Library which is designed for exactly this scenario.

ASP.NET MVC is Microsoft’s latest web application framework designed to provide an alternate, modern and cleaner web framework that is more aligned with the ‘spirit of the web’. This should not to be confused with Microsoft’s previous attempt at a web application framework which goes under the shorter and slightly confusing name of just ‘ASP.NET’.

First there was Classic ASP

Prior to Microsoft introducing its original ASP.NET the landscape for web frameworks was vastly different. At that time (well more accurately from authors view of that time :) many small websites were scripted with PHP and Perl languages which when used without a solid web-framework behind them (as most of them were) resulted in ‘spaghetti-code’ – a term used to describe the resulting complex code resulting from maintaining multiple callback execution paths and application and presentation logic kept within a single page. The main established competing frameworks in the enterprise space we’re from Java Servlets and Cold Fusion – which because of its commercial nature did not last very long in the ‘Open Web’.

All Microsoft had prior to this was classic ASP which in my opinion looked like the result of a C-grad student on a summer internship who was tasked with ‘just make something that works that outputs HTML so we can ship-it and silence vocal developers!’. The result of which was the very lacking ‘Classic ASP’ which was conceptually very similar to PHP but used VBScript or JScript as its core programming language and when called on to enable richer functionality answered by enabling developers to invoke ActiveX COM objects – needlessly to say did not perform or scale very well. Maybe I’m being too harsh here but the technology fell way below my expectations of a multi-national corporation who prides themselves in developing first-class software development platforms, tools and frameworks.

Microsoft was very late to the HTML game where most of their developers were still tackling the complexity of building windows applications with C++ or VB6. Luckily for them, the Servlet solutions provided by the competing Java frameworks seemed to be maintaining an unhealthy fixation having just discovered XML nirvana and thought that if they over-used it enough to configure absolutely everything that it would somehow land its authors in XML heaven. So productivity-wise the solutions ended being pretty much the same but the Java frameworks were quite rightly seen as the superior and more stable solution and as a result saw its usage increasing in the enterprise. Clearly Microsoft saw the impeding danger of the managed Java platform and knew that it needed to change course swiftly and offer a competing solution to fend off the Java attack if it was to keep developer mind share. So from the school of ‘Good artists copy great artists steal’ Microsoft initiated a company-wide effort to build a competing platform to Java and shortly after .NET was born. Although .NET being a very capable platform, the problem they still faced was they had a large market-share of developers who predominantly only knew how to develop Windows GUI Applications. What to do?….

and then came ASP.NET

Simple, provide a ‘Windows Forms-like’ abstraction to allow developers familiar with developing windows applications a state-full, event-based development environment similar to what they were used to when they were cutting their teeth on Windows GUI applications. This unique approach of developing websites comes with its share of advantages and disadvantages. The advantage of which were a shorter learning curve, a very capable GUI designer and a state-full event-based programming model which for the most part would let you get a lot of work done without needing write any HTML whatsoever.

Despite the short-term gains, these advantages can quickly evaporate for large projects. The learning curve is shorter but at the same time the curve is going the wrong way. Websites are inherently stateless and trying to make them state-full uncovers some of ASP.NET’s major limitations which include:

Being limited to a single FORM tag on a page which all subsequent requests are routed through. The event-based model provided is handled with server-side logic so trivial user interactions like changing the combo-box with an auto-postback requires a slow round-trip back to the server and the page to be completely re-rendered. In order to maintain page state a VIEWSTATE is kept that contains the state of each control on the page. Depending on the number and type of controls this VIEWSTATE can explode into a huge payload providing degraded performance for every request. The VIEWSTATE is core to ASP.NET’s and one of its biggest criticisms as it is effectively seen as the anti-web. In order to function it requires every request to HTTP POST an unreadable blob that is both undebugable with a packet sniffer and essentially unreproducible without manually clicking your way back to your desired state. This makes your application harder to test, debug, and maintain. Turning every request into a HTTP POST also has some disadvantages on their own. It breaks the users back button as HTTP POST’s are meant for destructive requests so browsers must prompt the user to make sure it is safe to do so. This has a direct impact on usability as in contrast to a HTTP GET request, the page’s url does not provide you context of your ‘current state’ (as can be inferred with RESTful urls), its not book-markable or transferable to someone else. It also has a wider impact in that the page state is not cache-able or indexed by search engines, etc. ASP.NET’s GUI designer (like all HTML designers I’ve ever tried) produce semantically poor mark-up which although great for building prototypes quickly become a burden to maintain a consistent style throughout. One advantage of ASP.NET that doesn’t get nearly enough attention is the composability that the state-full ASP.NET framework provides. This is evident by the rich 3rd party commercial ecosystem for ASP.NET controls – for which appear to be non-existent for alternate web frameworks. My personal belief for this, is its ability to encapsulate the entire state and lifecycle of a single control allowing authors to provider richer, more re-usable server-side controls. This feature allows accommodating developers to show off impressive rapid prototypes to their bosses where they’re able to drop a DataGrid control configured with a 1-line databinding and have it browse and edit their corporate RDBMS dataset.

Despite its criticisms I consider ASP.NET to be a fairly RAD environment and is still my first choice for developing small, simple Intranet or single-purpose applications. For large or public-facing websites I prefer to use the newer and much cleaner MVC. Incidentally MVC is not a replacement technology as Microsoft is planning to support both web frameworks for the foreseeable future.

Introducing the leaner, cleaner ASP.NET MVC

After having been largely successful in defending itself from its last foe with Java – Microsoft is finding itself again on the battle lines on the cusp of falling out of fashion with new developer mind share. This time its a result of a surge in popularity from the dynamic languages mainly Ruby, Python and PHP. They are now re-appearing armed with well established and proven web frameworks and a suite of large website backing proving their worth in the enterprise space. Ruby is leading the charge with Ruby on Rails while Pythonistas are sticking by their tried and trusted Django web framework. It’s hard to explain the reason for this new resurgence behind Dynamic language frameworks but I’m putting it down to a combination of the following factors:

Hardware is getting cheaper, and virtual machines and cloud computing are becoming increasingly popular. The performance issues of old have been mitigated, and scaling is now seen as more important since performance is now largely a hardware cost problem which thanks to Moores law is comparatively a lot cheaper to buy than programmers wages. Dynamic languages have proven themselves. Increasingly large websites such as Facebook, Yahoo, Twitter, etc have chosen to build on dynamic language frameworks and have made them both perform and scale well. There has been a shift in development methodologies towards a ‘best-practices’ software discipline where the most sought after traits in the Enterprise have now become: Unit, Integration, User Acceptance Testing, DDD, TDD, BDD, Agile, DSLs, etc. Although these approaches are not specifically tied to dynamic web frameworks methodology, it now supersedes the Enterprises previous only ‘safe-choice’ of using .NET and Java in the enterprise since they were considered statically-typed ‘safe languages’ which were served on industrial-strength multi-threaded app servers companies could trust. Using the above methodologies to create well-tested robust software that maximizes customer value and satisfaction is now, I believe the most prominent goal in software development. Since dynamic languages lack a lot of the compile-time safety found in statically-typed languages, developers are more inclined to write testable software and actually test their code. In keeping in-line with maximizing customer value many dynamic web frameworks prefer simplicity and Convention over Configuration allowing a lot more functionality to be delivered with the least effort. Spurred on initially by Google the web has become more powerful, faster and compliant then ever before increasing the possibilities and making the Web the first choice development platform for most class of applications. It seems that with this renewed interest in the web (I hate to say it – Web 2.0) has spurred a lot more research into what makes the Web great and the Internet work. Through this greater under standing, many people have attributed its success and the ‘Spirit of the Web’ to the simplicity and power of the HTTP specification and the REST (Representational State Transfer) software architecture which it was built-on. Many of the above points have either nullified ASP.NET’s inherent advantage and at the same time exposed its limitations. It is clear that ASP.NET’s state-full ViewState and direct access of sealed concrete classes were developed without any consideration of testing in mind as it is nearly impossible to test an ASP.NET website outside of a full integration test which takes a lot of effort and is cumbersome to write. So like any good software company Microsoft has recognized the current criticisms and shortcomings with ASP.NET and attempt to address them head on with their latest effort an entirely new solution written from the ground up to embracing the ‘Spirit of the Web’ providing a lean, clean, testable framework with powerful routing capabilities which enables experienced web developers the necessary tools to build REST-ful web applications.

ASP.NET MVC is now into it’s 2nd edition and has matured quite nicely adding some useful features along the way. It’s heavily inspired from other web MVC frameworks like Rails but also brings its own unique features to the table. It is generally well received and since is built using it – already has its proved-in-the-wild poster child :)

Model-View-Controller (aka MVC) is an architectural-style pattern aiming to split your application amongst well divided lines. When adhering to the pattern, your application is split between the Controller which accepts and validates user input, processes the desired logic and then dictates the final result by populating the Model (i.e. data class) and then electing the View in which to bind it to.

The MVC architecture originated with thick-client GUI applications which are in practice a very different technology to a web application where they are long-running, event-driven state-full applications where the Controller is used to manipulate the applications Model which the View generally Data Binds to, to reflect the change. This is in stark contrast with a web application which is generally short-lived, stateless applications that are centred around a ‘per-request’ execution model where instead of events ‘User Inputs’ comes in the form of HTTP network requests used to facilitate communication between client and server. Although very different in implementation the MVC concept remains fundamentally the same where the Model, View and Controller are kept in visibly separate tiers.

Inside the ASP.NET MVC web framework ‘user input’ arrives in the form of a HTTP request which is mapped to a Controller Action method. Where a Controller is any class that inherits from the Controller base class. It is mapped by convention as defined in the ASP.NET Routing module (a concept unique to ASP.NET MVC). From inside the Action logic the Model is populated which can either be a custom POCO class, a list of key values pairs set on ViewData Dictionary or both. Every controller action returns an ActionResult which most of the time will be View() which simply tells the MVC framework to pass the populated Model to a View with the same name as the invoked Controller Action method. Both the Controller and Model are standard .NET classes whilst the View is a basic .aspx page – ASP.NET’s templating language which simply executes code logic embedded inside the <% %> tags with the text mark-up surrounding it. Ideally MVC applications should only contain basic presentation logic in the View, by design most of the applications core logic should be contained within the Controller. Keeping the application logic separate from the presentation logic allows it to be re-used with different views. This is one of the ways where the MVC architecture promotes re-usability and a clean separation of concerns.

I think I’ll end this post here as its already too long – WordPress has a word counter here telling me that I’m dangerously close to surpassing the longest essay I’ve ever had to write for school! Its hard to believe but I originally expected for this to be an all encompassing post providing a brief history of ASP.NET before diving in and giving my first impressions on the newer MVC flavour. I don’t actually understand why its ended up so long since being a coder at heart am not really fond of writing documentation in any form – I guess I had a lot to say :)

Anyway stay tuned for the next post getting started with ASP.NET MVC and my first impressions of the new kid on the block.

Jump to Line
Something went wrong with that request. Please try again.