MVC (Model-View-Controller) Frameworks Versus HTML

Model-View-Controller (MVC) is a software approach to website building and display that separates what is called the "application logic" from the actual presentation. What this means in practice is that it permits web pages to contain just small amounts of "scripting," or PHP commands for automated actions, since the presentation portion of the page is separate and distinct from that PHP scripting.
A few quick definitions are in order. The "Model" means the actual data structures, the various functions that empower your pages to fetch, incorporate and even update the information in the database you are using. The "View" comprises all the information presented to a website visitor, normally a web page but possibly a page "fragment" such as a header or footer, an RSS (Real Simple Syndication) page or some other "page" type. Finally, the "Controller" is the intermediary among the Model, the View and any other necessary resources, all of which work in concert to reply to an HTTP "request" and generate web pages.
Programmers compete, you win
There are already various "coding companies" bringing the MVC workflow and structure to the application shelf. Some have a somewhat "loose" approach where Models are not absolutely required. If you can live (that is, if your pages can "answer the call") without the additional separation, or if designing and maintaining the Models is more complex than you like, you can simply build your site with just the Views and Controllers. Since you can usually incorporate your existing scripts, and develop custom core libraries, you get to work the way you want.
The notion that MVC is competing with HTML is incorrect, although some coders and site builders make a deal out of "MVC vs. HTML." Regarding RIAs (Rich Internet Applications, full-featured software packages that run in a browser), a leading software geek-Sho Kuwamoto, former Macromedia/Adobe engineer-opines that "MVC is probably not needed for most RIAs [and] is probably overkill for the vast majority of [Adobe] Flex apps." However, he also realizes that "MVC actually makes sense for the HTML-based world."
Peacemakers, not code warriors
This is hardly the type of "us versus them" talk some are using, and is much more sensible. Another sensible observation concerns the general tendencies exhibited by programmers and engineering managers, a leading one of which is laziness. This means "laziness" in a comparative way, in the expectation that only a truly serious, otherwise insoluble problem will motivate someone like Kuwamoto to get "into MVC [for] desktop GUI programming." For many programmers, separation between Views and Models was important, whereas separating out Controllers was in the "more trouble than it's worth" category.
About MVC making sense "for the HTML-based world," the explanation goes like this: There is physical separation between the View, which resides on the client computer, and the Model that is on the server. The logic for responding to user events is typically handled on the server, so does it even (or ever) make sense for Models to manage these events? The answer is a definite "no way," so you separate the Controller logic from the Model logic. HTML and MVC capabilities can support one another, as they should, rather than be looked at as an "either/or" situation.
Downsides updated, too
There are some unpalatable things about a hybrid approach, of course. There are architectures where a single Controller handles every one of the "actions" for the whole application. A few programmers may see this as a "good thing," while plenty of others would consider it a necessary evil, at best. Isn't the "World of the Giant Switch Statement" one of the very things every engineer in this niche wanted to avoid by adopting object-oriented programming?
With applications like Adobe Flex and others, you have these powerful, adaptable engines on the client side that can manage the complex logic-and access web services directly. The various forces that propelled the MVC model to the forefront should be reexamined in light of the goals of each individual. It is a powerful, even necessary, development, but certainly does not presage the "end of HTML."
For some applications it makes very good sense to separate out Controllers, and for particular components it makes sense to leverage the MVC method. For the majority of applications, however, separating Views from Models is the biggest winner in the workflow. Since, in the majority of cases, the Model part of the application comprises services that reside on an entirely different machine, the separation is something that you really have no choice about, anyway. Getting everything to work together to the greater good-the user experience-is the bottom-line goal for the scientists and the artists that join forces to push the Internet forward, often an inch or so at a time. Stay tuned to MVC, and HTML 5, or you will definitely miss something-and it could be soon, too!