This is a lengthy article that describes the history of how ASP.NET developed in the commercial environments and how ASP.NET MVC has attempted to usurp this powerful and mature environment. The points used to describe the advantages of ASP.NET MVC when compared to its more mature sibling are described and debunked at length as nothing more than personal preferences by developers who prefer the MVC paradigm.
In the end it is demonstrated that both environments are more or less on an equal footing and it is both marketing hype and preference that has forced an issue that in reality never needed to take place.
You would think by now that the debate between promoters of ASP.NET MVC and those that still prefer using ASP.NET Web Forms would have been settled by now. However, it isn’t and the most likely reason for its persistence is that it is more a sociological symptom of two generations fighting for their own recognition in this area of professional development than anything else.
Young technical professionals want to work with what is new, while older, senior personnel are quite content to continue using what they know works and what they feel comfortable with. As to the latter, everyone wants that no matter what age group they are a member of.
Nonetheless, both parties on both sides of the debate are in this case quite right in their reasons for working with their chosen web development platforms since it is what they know. And that is a rather difficult hurdle for either side to overcome if they believe they are producing quality deliverables.
However, if we were to break down the debate into reasonable and factual explanations for each side, you will find that ASP.NET Web Forms will still outdo the current rage for the use of its MVC counterpart. This may not be a complete technical win for standard ASP.NET but in terms of what is needed realistically within business organizations, there is no contest.
From a software engineering perspective businesses, to compete effectively require applications that can be implemented relatively quickly, efficiently, while maintaining a standard of quality in the deliverables. Surprisingly, at least for people new to the working world, most businesses (at least not ones in the United States) care relatively little for either efficiency or quality. If one, for example, were to be able to review the coding found in many US financial firms, one would be quite amazed at how poor the quality of the code actually is. In fact, in the early 1990s, The Financial Times of London reported on what anyone would have considered an appalling lack of standards and quality in the major Wall Street IT organizations. Given that such organizations have only the profit motive as an incentive, the lack of quality in their software development projects in many of these organizations still persists today.
Timeliness, efficiency, and quality in software development do not go together unless carefully managed by capable software engineering talent. And that too is missing from many US corporations since so many of these firms view such talent as an unnecessary expense like so much else they have successfully eliminated from the foundations of the IT profession. No surprises here…
This lack of enforcement in software development processes then leaves the doors wide open for the most common of all development paradigms, which is simply, “Get it done now!”
With such a lack of professional standards in place that maintain a general development quality across the US business environments, the doors are also left wide open for technical professionals to take it upon themselves as to the tools and standards they “want” to use.
This is quite a sought after characteristic for technical vendors who want to push new products into existing IT environments since it makes it far easier to do so. The result is constant technical advances in vendor tools, whether they are beneficial or not. Mix this with the constant introduction of new generations of technical personnel every 10 or 15 years and you have environments that are ripe for constant upheaval in the way that software products are created; hence, one of the major factors as to why there is so much unnecessary stress in business software development organizations.
This type of sociological landscape also makes it very easy for different generations of developers to come into conflict with each other as it has with the ongoing debate between promoters of ASP.NET MVC and its counterpart, Standard\Pure ASP.NET or what is also commonly known as Web Forms.
During the mainframe era in computing, senior professionals had far greater handle on how development was performed and younger professionals were taught to do as more seasoned personnel dictated. They had the knowledge that the younger personnel didn’t and so were able to demand certain things out of development environments. And if such environments were run as they are today, the United States would have come crashing down a long time ago.
Today, with the flexibilities of modern development environments any kid can enter it and tout himself or herself as knowledgeable in their chosen are of expertise, when in fact there is no way they can be. And preference is increasingly given to such younger personnel over the older ones in light of changing societal dynamics.
And this too has brought differing generations of developers into conflict with each other.
Yet, the reality in terms of the needs for quality software development have never changed but in fact have seemingly been ignored on an even greater level in the present than in years gone by and the consistent failure rates in software projects that hover at the same levels as when such statistics were first recorded over 40 years ago is a testament to the lack of quality in many such endeavors.
No doubt there were many failures in mainframe development as well but internal disciplines kept many companies from going down with them; and some of these failures were quite huge.
With the debate between ASP.NET MVC and ASP.NET, there is also another factor at play here that our erstwhile younger professional talent is not aware of and nor could they be. This factor is the way that web development progressed over the years.
The Internet, nothing more than a simple messaging environment that had no state, saw the development of increasingly sophisticated development tools that could generate the types of applications that businesses wanted as the new technology became increasingly popular. Thus, the progression follows from simple messaging protocols, to CGI and then Fast-CGI processing to the first full development environments that initially was introduced by Sun Systems with the Java standard and nearly parallel with them by Microsoft with their now “Classic ASP”.
Both environments were major advances in such developments. Mixed in with these developments were also such all-encompassing development frameworks as Cold Fusion and Web Objects from Apple Corporation. The former relied on its own type of markup and scripting, while Apple’s product initially insisted on the use of Objective-C but was later forced to convert to Java.
The stress and conflicts between all of these developments was quite intense and the only two left remaining once the larger part of the warfare had ceased would be Java with its web-based Java Servlets and Microsoft’s “Classic ASP”.
One must also take into consideration that at the time many developers were involved in creating applications using DBASE or one of its many variants, all of which allowed many developers to produce highly capable applications without a lot of low-level detail.
Thus, the underlying foundation for a desire for environments that were easy-to-use was laid down by these early software tools.
With Java development on the rise, Microsoft had to come up with a competing technology to remain relevant since at the time it would have been quite possible had they not done so, the company would have gone out of business. As a result, in 2001, .NET along with ASP.NET was released commercially.
ASP.NET was a complete boon to the web development world since it promoted a healthier way of developing such applications in that it discouraged the mixing of actual code within front-end markup. And it ran in a similar fashion with its framework as that of Java did against the JVMs.
Up through around 2010 ASP.NET became and maintained itself as the dominant development environment for web applications, though the Java environments were always nipping at its heels.
Java eventually gave way to ASP.NET as it was seen as simply too complex for most development efforts with an inordinate amount of tools to master along with less capability on the ease-of-use front. This was eventually overcome with the development of the excellent and freely available NetBeans IDE but by this point, ASP.NET had become more less the dominant force in the industry.
If you look at this type of progression then it is quite easy to understand why ASP.NET became so popular and though it had its faults, idiosyncrasies, and complexities it made web development a standard development expertise in the profession. No one complained or discussed much about its lack of “purity” or “rightness” in the way it handled the Internet. It did its job and many appreciated its capabilities.
The Open Source movement in one sense began to mature as an accepted methodology for software development as well in and around 2010 as there was the sudden appearance of several new JavaScript frameworks that made working with this “creaky” language easier and even more powerful than using straight JavaScript itself. However, even these frameworks couldn’t protect developers from all of the “gotchas” when developing for all browsers. Nonetheless, the push was on to make using JavaScript easier when ASP.NET MVC came out in its 1.0 version.
This was a turning point in the web development world since with the introduction of ASP.NET MVC came a new wrinkle in the promotion of this old but from Microsoft new paradigm. This wrinkle was the announcement from Microsoft that with new business requirements for the 21st century, new tools were needed to satisfy them.
This was a very curious synchronicity since no one ever really clarified what these new business requirements were since businesses kept on processing against the same set of requirements they had been working with for many years and the answer to this was to implement the MVC paradigm that by 2010 was in fact quite old. Makes a lot of sense doesn’t it?
In any event, many serious developers questioned the wisdom of this new Microsoft product introduction considering that many had the same concerns in that ASP.NET MVC appeared to be nothing more than a rollback to “Classic ASP”. And technically it was, more or less. However, Microsoft kept at it, generating new versions of this paradigm with additional capabilities and features until it met with a convergence of mobile computing advocates, open source advocates, and most importantly, an up and coming generation of professional developers who wanted to work in a “pure” form of Internet development.
Whatever this “pure” form of Internet development is it has never been adequately defined considering that given what is currently being done with the Internet there is really no “right” way to go about it.
The Internet relies on two primary processes; a “request” and a “response. How this is done is a matter of technically efficient internals and has very little to do with paradigms. That being said, the difference in quality and capability between a well-defined ASP.NET application and a similar one in ASP.NET MVC will be rather minimal.
Some of the complaints that have been made about standard ASP.NET are quite legitimate. However, to throw away such an easy to use environment when compared to its MVC counterpart is somewhat of an over-reaction.
Nonetheless, many who have adapted to the MVC paradigm have now presented this debate with a fairly standard list of items as to why the ASP.NET MVC paradigm is so superior to ASP.NET..
In a nutshell here they are…
- Enables the full control over the rendered HTML.
- Provides clean separation of concerns(SoC).
- Enables Test Driven Development (TDD).
- Easy integration with JavaScript frameworks.
- Following the design of stateless nature of the web.
- RESTful urls that enables SEO.
- No ViewState and PostBack events
Let’s take each argument and see if they still hold water. Remember, as ASP.NET MVC has been incrementally refined so too has ASP.NET and over a much longer period of time.
Enables the full control over the rendered HTML
HTML is nothing more than a markup language, which simply defines a web-page’s interface. Originally, ASP.NET did in fact take a lot of control over the HTML that its server controls generated but this has been scaled back substantially to the point that most HTML generation is now fairly standardized markup. Additional, developers are free to use HTML generic controls in place of standard ASP.NET server controls, which provide the same capabilities as pure HTML as well as the added benefits of similar server control capabilities.
The other major complaint in this vein was the ASP.NET generation of element ids that did not conform to standard HTML ids making it much more difficult to access them from JavaScript on the client. Again, this has been substantially rectified in addition to the earlier fact that by using JavaScript element id extraction processes, a developer could in fact access such elements by the actual element id and not the one generated by AP.NET.
Provides clean separation of concerns(SoC).
“Soc” has been a standard in quality development for many years. Originally it was more well known as modularization of a project and its components, which was and still is a standard concept in N-Tiered development.
However, beyond this what could any developer really want in this case? “Soc”, again is a paradigm, and it is up to the developer how well he or she defines and modularizes the components in any application.
If the complaint is related to the use of ASP.NET’s “code behind” components and how they are used, well this is not a function of any paradigm but how a developer implements them. It is very true that many ASP.NET web applications have been made quite messy as a result of bloated “code behind” modules. However, if we are talking “SoC” here than it should have been realized long ago that “code behind” modules were to be only used as manipulators of their corresponding page’s interface and a dispatcher for all other non-interface related functionality; nothing else. The fact that so many have abused thie idea behind “code behind” modules is not a fault of ASP.NET itself.
The definition of “Soc” that is found on Wikipedia is as follows…
“In computer science, separation of concerns (SoC) is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern. A concern is a set of information that affects the code of a computer program. A concern can be as general as the details of the hardware the code is being optimized for, or as specific as the name of a class to instantiate. A program that embodies SoC well is called a modular[1] program. Modularity, and hence separation of concerns, is achieved by encapsulating information inside a section of code that has a well-defined interface. Encapsulation is a means of information hiding.[2] Layered designs in information systems are another embodiment of separation of concerns (e.g., presentation layer, business logic layer, data access layer, persistence layer).
The value of separation of concerns is simplifying development and maintenance of computer programs. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently. Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections”
Reading this definition it is easy to see that it stipulates this is a design principal not one of development and as such, no development paradigm can enforce it. Thus, ASP.NET MVC development can just as easily create bloated code sections within its various required modules (ie: views, controllers) as one could with a “code behind” module.
Thus, using this concept as a defense of ASP.NET MVC over that of standard ASP.NET, is a fairly weak defense at best.
Enables Test Driven Development (TDD)
First of all, “Test driven Development” or “TDD” was around long before ASP.NET MVC came about. In fact much of the development of this paradigm was in fact done against both ASP.NET (starting with ASP.NET version 1.1) and Windows Forms development with the early introduction of the “NUnit” testing tools.
Second there is no industry evidence whatsoever that TDD is superior in any way to that of similar quality traditional testing. The fact that some developers have found that it works better for them over traditional techniques does not mean that TDD is better but that it has been found to be so on an individual basis.
Third, there is still a lot of ongoing discussion in the profession as to the actual merits of TDD when compared to traditional testing methodologies. And no consensus has actually been reached except within those groups that support it and those that don’t.
TDD is a tool as well as a concept; if you like using it, great. However, to say that this cannot be done against an ASP.NET application while it can be done with an ASP.NET MVC application is somewhat of stretch.
Easy integration with JavaScript frameworks
All JavaScript frameworks have their drawbacks no matter how well developed since there are simply to many differing browsers with their own set of variables to contend with.
It is true that such frameworks may more easily integrate with ASP.NET MVC applications but then again, with ASP.NET they are not so much of a necessity since ASP.NET is its own framework. In an ASP.NET application you are not supposed to be integrating so much JavaScript except where required and for the most part all you should ever need in this vein is “jQuery”.
The fact that ASP.NET MVC does dispose itself to JavaScript frameworks at all should be a cause for concern. Some of these frameworks are quite bulky and add as a result add to the heft towards a “fat client”. As such, these frameworks in one sense contradict the concept of “separation of concerns” since with MVC the client is now in many cases, expected to do a lot of processing all to avoid a trip to the server, which with ever increasing speeds over the Internet (at least in Europe; in the United States we have mediocre speed that is outrageously priced so our corporations can make their profits), it gets a little ridiculous when you think about it.
This idea that that these frameworks are efficient replacements for similar processes with standard ASP.NET is a stretch considering that the Internet is designed around concurrency and not performance. And the idea to mediate concurrency efficiently is to modularize the overall application not move the bloat from the backend to the front.
Following the design of stateless nature of the web
All web development environments are designed to deal with the stateless nature of the Internet; otherwise they wouldn’t be web development environments.
Is it conceivable that by using ASP.NET MVC some type of magic state elixir is being used that standard ASP.NET is not designed for? Every web application requires some capability of maintaining state between web pages unless of course a web application is comprised of a single web page.
There are many ways to manage state persistence along with the stateless nature of the Internet. And ASP.NET MVC does it no better or worse than ASP.NET (or visa-versa) considering that both have the same capabilities at their disposal. The fact that state can be passed back and forth in an ASP.NET MVC application via objects bound to a view does not make it any better than any other methodology that standard ASP.NET may use. You have to save it somewhere using some type of mechanism.
It is highly unlikely that one mechanism is so vastly superior to any other in the overall scheme of things.
RESTful urls that enables SEO
ASP.NET has the capability to implement SEO friendly URLs and has had it since Visual Studio 2010.
Nothing more needs to be said here…
No ViewState and PostBack events
As many professional developers have said many times; YOU DO NOT HAVE TO USE VIEWSTATE in an ASP.NET application. That has always been an option with ASP.NET. The fact that it is available with ASP.Net does not make the paradigm any less capable.
As it regards “Post-Back” events, this is also optional with ASP.NET. You may use post-backs or standardized AJAX calls from within an ASP.NET web page.
In both cases, it is all how you design an ASP.NET application and not what the framework enforces.
>>>>>
Now there could very well be other reasons for preferring ASP.NET MVC over standard ASP.NET but the items above are the fairly common points always listed by proponents of the MVC paradigm and the ones used to deride its older counterpart. And as it has been shown, all of the items when understood properly have very little real meat to them.
When it comes right down to it, the demonstrably more vocal proponents of the ASP.NET MVC paradigm simply prefer to use it instead of its much older sibling. And that is fine.
However, the argument that it is somehow superior to ASP.NET does not hold much water. But we have to give the current crop of younger professionals their due since they really won’t know any better. But they will when the vendor product cycles change again in a few years as they look to a new generation of developers younger than the current one. And then these current young professionals will be having similar arguments with those younger than they as a new generation lets the pendulum swing back to easy-to-develop-and-implement environments.
That is how it has always been in the IT profession since vendors need to keep making money and not because any new methodology or technique is so vastly superior to a mature one that has performed well for a number of years.
In the end, such debates are fruitless because with each iteration of hardware the software must adopt in a manner that over time demonstrates that there is no right or better way; just the way that works best for an individual professional…
TECH NOTES 