Re: MVC not suitable for Web Development

On Mon, Jun 18, 2012 at 7:19 PM, Unmesh Joshi <[email protected]> wrote:

> **
> I recently blogged about how MVC, which is used by many popular web
> frameworks like Struts, Spring MVC and Even Play, is a wrong model for web
> development at
>
> http://webdevlopmentpatterns.blogspot.in/2012/06/mvc-not-suitable-for-web-development.html
>

I never cared for the phrase "MVC" to represent Frameworks like Struts and
Spring "MVC". I never felt it was a good fit.

I've always preferred "Action Framework", because I think it better models
the application, even though some "MVC"-eque parts are used in the back end.

This is also to distinguish such frameworks from the Component Frameworks
like JSF, Play, or the original .NET. Those also use MVC at their core, but
on a much more granular level (the component) than the Action Frameworks
(which works more at the action/page/resource level).

Action Frameworks (AF) play "better" with the web and HTTP than the
Component Frameworks (CF). I don't think the AF hide HTTP at all, or when
they do, it's much less than the CF do. With something like JSF or Play,
etc. HTTP is completely buried. As a rule, they tend to POST for everything.

AF assign logic to URLs more directly. In fact, one of their primary goals,
especially early one, was binding URLs to logic, logic that can represent
resources.

Obviously, in the early days, it was all about forms and pages, because
that's the meat and potatoes of web applications, before the "formality" of
resources and REST etc.

The biggest crime of the legacy action framework is they tend to hide the
HTTP method, conflating GET and POST more often than not, and having little
support for the others. This is not a capital crime however, since
pragmatically when dealing with raw web browsers, that's all you can get
anyway. Recall that almost all of this is not so much influenced by HTTP,
but by the browsers that leverage it. Only in the past few years has "pure"
HTTP processing risen, especially with the rise of XHR and ad hoc "RESTful"
*cough* web services.

Adding method support to the AFs that don't support it is really
straightforward.

More modern "rest" frameworks like JAX-RS offer more robust binding and
dispatch options based on URLs than the earlier AFs, simply because of the
demand for even more exposure to HTTP. They also offer better support for
content types other than HTML. But these are evolutionary frameworks, not
revolutionary. The basic concept of mapping URLs to logic is fundamental,
but the modern ones add more features for better access to HTTP methods,
content type management, etc.

JAX-RS works just fine as a conventional Java AF, with requests coming in,
logic being peroformed, and results displayed through forwarded JSP. it's
just not marketed as such, and there are few tutorials demonstrating it
used as such.

The older AFs aren't going anywhere, their methodologies are quite valid
for a wide range of use cases on the modern web, they're well documented,
and there's a huge amount brain share trained in the techniques. Their
advantages far, far outweigh any ideological warts in terms of their
conformity to a specific dogma of what web development "should be".

I've always advocated that "Web Apps" and "REST" are not, nor do they need
to be, the same thing. They fit different domains of application types and
use cases. The modern AFs are simple to use, wafer thin in terms of
abstractions, and quite transparent, with very little black magic. You can
easily understand what should happen by looking at an HTTP request. Yet
offer enough functionality and flexibility to remove a lot of the tedium of
web development today.

Regards,

Will Hartung
([email protected])

-- 
CONFIDENTIALITY NOTICE: The information contained in this electronic 
transmission may be confidential. If you are not an intended recipient, be 
aware that any disclosure, copying, distribution or use of the information 
contained in this transmission is prohibited and may be unlawful. If you 
have received this transmission in error, please notify us by email reply 
and then erase it from your computer system.