Re: MVC not suitable for Web Development

MVC is a totally different concern and 'Web' frameworks which are
written based on MVC abstractions ignore Web. There is no concept of
resources, representations and HTTP verbs. It spoils the language and
corrupts developer thinking.
The language we use and names we chose while coding is extremely
important (as highlighted by DDD).  The language of Resources,
Representations and uniform interface (GET, POST, PUT, DELETE) is the
'ubiquitous language' of the Web.
That should be reflected in the code.

On Tue, Jun 19, 2012 at 1:25 PM, Kristian Rink <[email protected]> wrote:
> Hi there;
>
> just a few thoughts:
>
> Am 19.06.2012 04:19, schrieb Unmesh Joshi:
>
>> 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
>
>
> Well in example in Spring controllers, nothing keeps you from making use of
> configurations or annotations to map URI patterns and HTTP verbs to
> @Controller methods, and likewise you can make these methods work with
> Request/Response the way you possibly would by just using plain HttpServlets
> or something the like. From that point of view, I don't see these things to
> be too bad. But generally indeed it seems these frameworks are built around
> a completely different idea, just considering the "view" approach in Spring
> MVC which, though not limited to that, still is pretty much centered around
> the idea of providing "views" in terms of user interaction, thus
> human-parseable HTML forms.
>
> You can do way more with Spring MVC, but ultimately it boils down to this,
> and this also is how tutorials seem to be crafted. This might be good to
> those who already are knee-deep into HTTP while it might make things
> difficult to others trying to start out right this.
>
> One word on SOAP however, from my point of view: Yes, SOAP folks did decide
> to just using HTTP as a transport protocol, which however, as far as I see
> things, is not a mistake but an actual design decision, and not a bad one
> from my point of view. Maybe there are smart and sane use cases for both. :)
>
> Cheers,
> K.