On Wed, 21 Dec 2011 23:00:44 +0100, Steven Huwig <[email protected]> wrote:
On Dec 21, 2011, at 2:07 PM, "Fabrizio Giudici"
<[email protected]> wrote:
On Wed, 21 Dec 2011 16:09:21 +0100, Steven Huwig <[email protected]>
wrote:
My opinion is that the term "MVC" is often misapplied to simple
separation of presentation from program logic. Moreover, it's an
architecture that doesn't actually need to be reflected in the code
structure of typical web applications. In a web application, the
browser is the view, the web server is the controller, and whatever
backend code there is is the model. There's often no need to try to
subdivide the backend code into MVC again, because the backend code
should be leaving presentation up to the browser.
I think I didn't get the point. Can you elaborate?
Well, I'll try to explain by example. MVC literature talks about which
objects should communicate with which other objects. For example,
updates to the model should be transmitted to any observing views --
but in "web MVC" there's no conventional means to implement that. Web
servers do not push out data to clients as a general rule.
Ok, it's depending on the context. Many technologies allow to do push even
in a web environment and in those cases a "more traditional" MVC fits
well. See also your latest observation and my comment below.
Moreover, in server-side code, executions typically last only as long as
a page load takes, so there's rarely any use in setting up observers for
changes to the model.
This happens with page-oriented web technologies. If you go with AJAX/HTML
5.0 this is no more the case, as you don't have a page any longer, and
basically you are pretty close to doing similar things than a regular
desktop application.
A good half of the power and relevance of MVC is tied up in the fact
that it's for interactive UIs in object-oriented systems. Applying it to
distributed web servers and an infrastructure that wants to be stateless
doesn't seem to help very much.
I don't see the "stateless" thing a relevant point. For instance, the
"model" (but again, see below) could be just the listener of an event bus
(and there could be ever zero state in the system, only message flows),
still you have a controller that upon reception does something and
populates a view.
That's just a recipe for confusion then, especially since the original
sense of MVC is still alive in iOS and various JavaScript frameworks. A
Spring MVC controller is nothing like an iOS UIViewController, so why
try to shoehorn them into the same "pattern?" That kind of imprecision
only serves to make the term less useful. If we want to say "separate
presentation from logic" then we should just say that.
This is a very good point indeed, so we have indeed a vocabulary problem.
There are also things such as Model-View-Presenter,
Presenter-Abstraction-Control, and others, and generically they are
referred as MVC interpreting the term as "something that decouples...".
Probably what I'm referring to is more PAC than MVC.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
[email protected]
http://tidalwave.it - http://fabriziogiudici.it
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
