Software Engineering: The ASP.NET (Web Forms) – ASP.NET MVC Debate; A Software Engineer’s Perspective

Now that ASP.NET MVC is headed into its third release version there is enough information out and about as to whether it is a viable platform for developing production implementations as compared to its more mature sibling, Web Forms.

For any developer who decides to do such comparative research, he or she will find a plethora of articles and documents touting the efficiencies of ASP.NET MVC over its older, more embedded forbear.  And all of these writings will be very much on target from a technical perspective.

ASP.NET MVC does in fact use the reliable MVC design pattern to more efficiently separate the web-based interface from the support modules allowing for more efficient testing of such constructs.  ASP.NET MVC does take advantage of the stateless nature of the Internet in a more direct way by not hiding its limitations from the developer.  ASP.NET MVC does use more efficient URL mapping instead of the bulkier page-life-cycle methodology that Web Forms uses tying the corresponding interface to a single middle-tier module (code-behind).

And ASP.NET MVC, though nearing its version 3.0 release, is still relatively new for the .NET community making it more tantalizing than using a more mature technology.

All of this is good from a technical perspective as it was good for Java at the time it was being touted as the new development paradigm for the Internet.  But ASP.NET MVC shares the same weakness that has always plagued the Java Community;  it is promoted by purists and evangelists for the sake of the technology and not its actual relationship to providing efficient methodologies for getting jobs done quickly, efficiently and with levels of corresponding quality.

Younger technicians with a penchant for using the latest technologies available or the slightly older ones who have been severely inundated with the latest techno-babble from vendors and vendor-evangelists see nothing wrong in merely using the technical advantages of newer technologies when compared to similar disadvantages to older ones.  However, does this in of itself make it the correct basis for decision making processes for real-world application implementation?  In a word; No…

Making such decisions in the chaotic, business world that we inhabit today takes experience in seeing the varying forms of failures that projects can experience from bad decision making.  And with a continuous software project failure rate still hovering around 70% since the inception of modern, application development in the 1960s, one has to be cognizant of what causes such failure in order to provide a better than average chance of having their project implementations succeed.  Unfortunately, most developers and technical managers are blind to such foresight since few take the time to study the actual requirements of software development and if they do, they rarely stand by proven methods of success.

Most often people simply give in to the stresses of just getting the job done as a result of supervisory pressures and tight deadlines.

Moving from a rather complex Web Forms project on my last consulting assignment which wrapped up this past August to my current position, I was recently exposed to the stark realities of rushing to use newer technologies based on their technical advantages over more mature options.

Moving into a new ASP.NET MVC project was admittedly very much like being thrown into a lake of icy cold water.  All of the familiar underpinnings of existing Web Form paradigms were gone replaced by an intimidating but somewhat familiar environment of “Classic ASP” but on steroids.  Despite the fears of many Web Form developers, that ASP.NET MVC is a step backwards towards the older methodologies of implementing web applications, such reactions are based upon only a knowledge of what this framework appears to be on the surface.

There is a lot more to it than just a reflection of “Classic ASP”, though it is very easy to understand why so many would have such a reaction.  I have done a number of years of “Classic ASP” as well as the equivalent number of years doing Web Forms and my initial reactions were exactly that of a giant step backwards.  However, once you get involved in understanding the intricacies of this new framework, you quickly find that the only thing “Classic” about ASP.NET MVC are the server tags mixed in with the HTML markup…

That being said, there are however, some severe penalties for using this platform without first thoroughly familiarizing oneself with it.

ASP.NET MVC is not a platform that is ready for “prime time” if your project has strict deadlines.  It is not ready for “prime time” if the project team is not familiar with the tools required to replace those that had become so familiar when developing with Web Forms.  And it is most definitely not ready for “prime time” if the project manager has no time for that level of “project risk” that will have to include a major learning curve for the team.

Simply put, ASP.NET MVC is not a “Rapid Application Development Environment” or “RADE” if one wants to conjure up similarities with the well-known insect terminator product…  It is simply designed to be too low-level for want of a better description in order for it to be able to provide quick responses  in terms of development efforts.  ASP.NET MVC is also an environment that enforces software engineering paradigms simply by its very nature.  And software engineering paradigms are both misunderstood and distrusted by most technical managers since all they see are the additional time requirements that such paradigms incur when scheduling a development project.  This in turn has encouraged such fads as XP and Agile programming both of which are no more than what we used to call “guerilla programming” in the mainframe world; fads that encourage minimalistic planning while turning out small bits of working code with little in-depth knowledge as to where the overall project should be heading.  Even planning in many instances is now considered a waste of time by many project managers; just “code & go” is what is actually wanted in many situations.

Because of its adherence to software engineering paradigms, ASP.NET MVC can literally sink a project if the user or client overseeing the project is in a constant state of chaos due to their own inability to articulate exactly what it is they want from the software development effort they have commissioned.  This is because ASP.NET MVC forces development to occur in a certain manner which also encourages a lot more fore-thought on the part of the development team.

However, one thing that can be said about this new environment is that once you get a working knowledge of it, it is not only quite a bit fun but terribly addictive because of the fact that it does provide such a nice way to implement a project’s middle-tier.  Once mastered, you are forced to reconsider development with a Web Form model merely due to the elegance and simplicity of the ASP.NET MVC paradigm.

Unfortunately however, such views are the sole purview of technical professionals and do not align with those of our clients.  And just as unfortunately, inept clients and users are pretty much the norm in our profession not the exception.  Thus the first hurdle that any new project engaging with the ASP.NET MVC environment should resolve is a good working control over how and when the user can make requirements changes.  True, they may be the ones footing the bill but it would behoove the project manager on such a project to make the user(s) understand that making chaotic demands on their development efforts will only guarantee that the bill will be much higher than desired.

Just as importantly and before and project team jumps into the use of ASP.NET MVC, the project user must be made to understand the benefits of each of the environments.  Thus if their overriding concern is quick development due to strict deadlines, than the choice should be made for the implementation of the Web Forms paradigm with the understanding that this paradigm will also not have the performance benefits that ASP.NET MVC naturally has with its bypassing of the heavier Web Form page-life cycle.  That being said, it should be noted that there are many things that can be done to improve the performance of Web Forms including the use of the highly efficient AJAX library, Gaia AJAX (http://gaiaware.net/).

If however, the client or user wants extensibility with an embedded level of maximum HTTP performance than the choice should than easily be for ASP.NET MVC.

But even here there are certain things that require understanding to properly implement an ASP.NET MVC project.  First and foremost, forget all of the hype that has been currently surrounding this new ASP.NET framework.  It will not do you any good if you run into trouble.  The hype comes from mostly technology evangelists who can’t see past their noses when it comes to adhering to good software engineering paradigms especially the paradigm about using the right tools based on the knowledge of the resources involved and the criteria of the project.  Yes, ASP.NET MVC technologically is superior to the Web Forms model but this is not a real-world consideration unless the client is adept enough to understand the ramifications that come with it.

And looking at ASP.NET MVC as a possible or eventual replacement for Web Forms would be a serious mistake when considering it as opposed to the older technology for a client’s requirements.  With its rapid development qualities along with a very large third-party support community, Web Forms is not going to disappear any time soon and nor does Microsoft have any plans to eliminate it from its development software stack.

ASP.NET MVC adheres to the MVC design pattern.  It does this rather altruistically since it has its origins with the ASP.NET MonoRail project (http://www.castleproject.org/).  The MVC design pattern is not an easy one to wrap your head around quickly if you have never used it.  And you will find that even the leading writers of ASP.NET texts on the subject also found similar difficulties in moving from the Web Form paradigm to that of MVC.

In a nutshell, and a very tiny one at that, ASP.NET MVC is made up of three critical components; the “View”, which is your web-page interface (actually any interface that is sent to the client), the “Controller” (and you can have more than one for any single web page) that processes the HTTP requests to the server and back to the client, and the “Model”, which in effect is the data structure that the controller will use to provide the “View” with its content.

In reality, this design pattern should actually be called VCM (View-Controller-Model) for the simple fact this is how most developers will see the relationships between these components.  Calling it MVC is actually a source of a tremendous amount of confusion which isn’t helped by the technical manuals that promote the theoretical methodologies for understanding this paradigm.  However, the reason for this moniker is that the theory behind this paradigm is that the “Model” is the most important aspect of it since it is the data definition behind any “View”.

I find that, when attempting to learn a new technology, a lot of theory just gets in the way and adds confusion to the subject matter.  And this is mostly because as professional developers we do not use theory to implement projects but in fact, use patterns of development processes that we know will work properly and get the job done.  This is also why design patterns are not very popular and tend to be used again by technology evangelists and those favoring theory.  There is nothing wrong with design patterns except for the fact that developers for the most part do not think in those terms.  And as long as most development projects are run in typical slipshod style, they never will.

When we compare ASP.NET MVC to the older Web Forms model in terms of project’s technical implementation, what becomes quickly apparent is that ASP.NET MVC has little third-party support when compared to the more mature Web Forms model.  If you look for tools to provide additional support for an ASP.NET MVC effort, what you find most commonly are the top tier JavaScript libraries such as jQuery (made part of a new project implementation by Visual Studio), MooTools, ExtJs, and PrototypeJS; none of which provide any “out of the box” capabilities similar to server controls.  However, both jQuery and ExtJS have quite a number of component plugins that can be used to extend the capabilities of both libraries.

All four libraries provide superior ways of handling client-side JavaScript implementations but there are learning curves involved for each as well as a requirement to develop extensive JavaScript code in order to provide similar functionality on the client as server controls do in the middle-tier.  This additional code development also drives up the time required to debug and test implementations forcing developers to literally use two different environments to debug their implementations; client-side debugging tools such as Firefox’s, “Firebug” and IE’s “Developer Toolbar” for the fornt-end and Visual Studio for the middle-tier.  So in this particular instance and others similar to it, making use of such libraries ease the implementation of client-side functionality but adds additional time required to do so.  Even if one is knowledgeable of a specific library it still requires the coding to make things work.

The question then is why bother when you have a lot of this already done for you in the form of server controls?  The answer given… it provides better performance without the extra baggage that server controls bring along with them since such implementations are all based upon AJAX.

However, this is only partly true.

What you are trading with in ASP.NET MVC is less server-control view-state baggage for a similar amount of JavaScript for the more complex web pages.  True, JavaScript does not expand the way view-state may with a data-grid or a grid-view but a heap of JavaScript has as many penalties for too much of it as does markup.  And if you need to present your data in a complex display such as a data-grid, the JavaScript to do it will all be sitting at the client.  The code that has to process these implementations has go somewhere…

In the end, like everything else in software development, there is little advantage to one or the other, its merely the advantages and\or disadvantages that you decide to accommodate.  And if you are crunched for time, using such a minimalistic framework as ASP.NET MVC for a highly complex project will not mitigate the stresses of pending deadlines when having to work much harder to get the same work done that the Web Forms model already provides for with many existing and mature tools.

A few major software houses such as Telerik Corporation are beginning to offer competent controls for the ASP.NET MVC framework.  However, after the length of time the MVC implementation has been available, the amount of support is not gaining a similar broad base of momentum as was done with the server control vendor community.  In addition, such controls are similarly JavaScript based as the previously mentioned libraries so there is really nothing new here.

ASP.NET MVC evangelists are touting the idea that such support will be forthcoming but don’t hold your breath.  As long as Web Forms is the easier of the two methodologies to use to implement web-based applications quickly, this is where third-party control vendors are going to continue to emphasize their product development efforts.  And there is little money to be made with JavaScript libraries as all the current popular ones are free.

But let’s forget for a moment the technology support for such development and take a look at the learning curve involved to implement a complex ASP.NET MVC application.  Where Web Forms attempted to hide the underbelly of the Internet from most development efforts (and did a reasonable job of doing this as well), ASP.NET MVC comes with the requirement that you actually have to understand how the Internet works with knowledge requirements that involve routing mechanisms, POST and GET processes, Request and Response processes and the like while intermixing all of this with a lot of JavaScript and AJAX processes as well.  What was originally done at the server level as well as the client is now turned on its head with the admonition that more can now be done at the client providing a better “user experience”.

However, much of this promotion of ASP.NET MVC is based upon the idea that it is also “now” the “correct and elegant” way to do web-development  due to its compactness as well as the correct technique for working with the stateless environment of the HTTP protocol and topology of the web.  For once I have to agree with such popularizations; ASP.NET MVC does in fact work at a more natural level with the Internet’s topology. Nonetheless, this criteria for ASP.NET MVC is not a real-world response to the nature of most software development efforts but instead a purist view for the use of a technology for the sake of technology; a deadly mistake for its adoption when schedules are tight.

The idea of Rapid Application Development is NOT to go low-level as ASP.NET MVC encourages but to keep it at a substantially higher level in order to get the job done quickly and efficiently.  And this is where ASP.NET MVC simply cannot currently compete with the Web Forms paradigm in this instance.

The idea that as the Internet has evolved  along with newer types of business requirements along with it is complete and utter nonsense.  The Internet has neither evolved since its inception in the 1960s and 1970s and nor have business requirements changed.  The internet still retains the same topology and protocols it was given with its inception and business managers are still making the same unplanned requests they have always made towards IT personnel with the only difference being that they have been subjugated to much more propaganda by the technology vendors who are all promising “magic bullets” to their business issues.

Nonetheless, ASP.NET MVC is above all an excellent choice when and if a development team has the time to do the job properly and everyone is well versed in the areas of expertise that are needed to support the project due to the learning curves required to become competent with this framework.   It is not a good choice when basing such a decision on the promotions of technical purists, engineering types, and technology evangelists.  Such promotions are often short cited,  self-serving, or the result of narrowly focused training.

Last but not least is the perverted admonition for this new paradigm that by using it will provide an elimination of  “the spaghetti code that Web Forms often encouraged”.  In fact, for those of us who did “Classic ASP” for quite a number of years, this is the same exact reasoning that was given for moving to the new ASP.NET Web Forms model when it was first commercially released in 2001.  In fact, Microsoft is great at regurgitating the same reasons for using a new technology that were used to get rid of an older one.  Stay in the field long enough and it gets sadly very repetitive.

There is no such thing as a paradigm being used to prevent sloppy coding habits.  Any language and any paradigm can be turned into a complete mess.  You just need the right incompetents to do it or the lack of time that prevents quality personnel from developing quality code.

Does all this mean that ASP.NET MVC has a questionable future for real world applications? Absolutely not!  On the contrary, ASP.NET MVC has a very bright future due its natural bent towards the Internet architecture

It simply means that it is not a good choice currently for getting a job done efficiently and quickly when a client or a corporate user is controlling a project’s scheduling and they are keeping to very tight deadlines.  However, the more important aspect of this discussion has nothing to do with which model works better or doesn’t.  Instead it has to do with the realities of Internet development.  And those realities include the fact that the majority of tools used to develop web applications with are nothing more than “kludges” or “parlor tricks” based on a current set of circumstances and this is especially true for the popular AJAX paradigm.  By now with the amount of effort and time that vendors have expended in developing tools alongside the efforts that developers have expended in implementing such applications one would think that a standardized framework would have been refined well enough by now to offer pretty much what any web application requires in terms of acceptable performance and user-interface capabilities.  Instead the industry has bounced from scripted languages to compiled languages and back again all the while throwing the Internet development processes along the way into the same turmoil.

Such turmoil serves only one purpose and that is to support the capabilities of vendors to maintain their brand and make revenues on them.  Whether you elect to  use an MVC paradigm with the .NET framework or not will not make a stark difference in application performance with well-designed and well implemented development efforts in which either are properly tuned for performance benefits.  Such efforts will most often provide similar levels of performance since Internet performance is still mostly a factor of the hardware and bandwidth supporting a specific application as well as the amount of data being sent to and from web-pages.

Black Falcon

The following links, tools and books will provide enough in-depth knowledge to help you decide if your next production project has the criteria that could support an ASP.NET MVC implementation…

Dino Esposito on ASP.NET MVC…

Dino Esposito provides the most balanced coverage on the ASP.NET MVC framework that I have seen to date…

http://msdn.microsoft.com/en-us/magazine/dd942833.aspx#id0080027