Re: MVC demistified [was Re: [RT] SpitScript - B-Logic that doesn't suck ]

[Ovidiu Predescu <ov...@apache.org>]

On 6/24/02 8:23 AM, "Stefano Mazzocchi" <st...@apache.org> wrote:

> Nicola Ken Barozzi wrote:
> 
>> Let's remember that flowscript is a potential liability in a sense that
>> it can be really abused in doing what you and I know it shouldn't do.
> 
> Agreed. In fact, as others already pointed out, it might become a
> gateway to abuse and concern overlap. But I think this could be said of
> actions.
> 
>> BTW, just a RT... this means that we would have MVFC: model, view, flow,
>> controller... :-?
> 
> Finally, you are scratching the surface and looking into it: there is no
> MVC on the web. MVC assumed a stateful environment. The reason why
> people are so excited about MVC is that is the most ovbious instance of
> the SoC metapattern.
> 
> (yes, it's already hard enough to abstract to patterns: abstracting to
> patterns of patterns is *much* harder, even for trained programmers).
> 
> So, MVC is just one of the possible ways you can separate concerns and
> (I keep on saying this), it's *NOT* the best way to implement web
> applications, no matter how hard you try.
> 
> The reason: http intrinsic statelessness.

I think Web applications are in fact stateful. I don't think the inherent
statelessness of the HTTP protocol changes this fact.

Comparing with a GUI application, you'll find lots of similarities, where
mouse clicks and keyboard clicks are translated into events which are sent
to the application. GUI applications have a run loop, the equivalent of the
HTTP server, which just listens for new events and dispatches them to the
appropriate receivers.

The fact that HTTP is not stateful is by now worked around with cookies or
other techniques which hide this aspect, and make it irrelevant. The end
result is that Web apps are comparable with GUI apps in terms of model.

> So, let's dissect MVC:
> 
> 1) view is the concern that everybody identifies easily. It doesn't
> matter what technology you use for this, but template systems (think
> SSI) were invented the day the dynamic web was born.
> 
> 2) model is harder. For GUI widgets it's easy: it's the OO abstraction
> of the concept implemented by the MVC pattern (say: a button, a text
> area, etc..) What is the model of your "webmail"? In GUIs, the MVC
> granularity is for the single widget, what is the model granularity for
> web applications?
> 
> So, first problem: what is the granularity of MVC? For GUIs is the
> widget (if you disagree, tell me: what is the "model" of photoshop?),
> for webapps what? pages?
> 
> No, pages are too small and webapps too big. Then what?
> 
> 3) controller is a nightmare: where is it? MVC creates a nice SoC
> because:
> 
> - view -> presentation concern
> - model -> data concern
> - controls -> logic concern
> 
> but it assumes:
> 
> - granularity is coherent
> - state transitions are stateful
> 
> I hear you saying: it's up to the implementation to add state to the web
> application transparently. It's easy to do.
> 
> Sure, but you are still left with the problem of identifying which is
> the best granularity for those MVC realms. Pages are too small (can you
> have a different controller per page? doesn't make sense), webapps too
> big (can you have a single model for the whole webapp? nah), sessions
> too heavy (can you have a single view for each session? well...).

I think the right granularity is the unit of functionality of a Web page. In
the Jakarta world, the closest encounter to this is the portlet idea, which
embeds the whole functionality of a Web page component in a type of
component, that has View and Controller capabilities, and invokes the Model
from its action methods.

We probably need to think along the same lines of this portlet idea. But
instead of the portlet thingy, we should have many smaller components which
are smaller MVC instances composed of their own flow, subsitemap and
business logic, which is able to represent them. This is very close to the
Cocoon blocks idea, at least the way I see it.

> Result: those who say "let's use an MVC framework" are indeed saying
> "let's use a framework that allows us to separate concerns", the problem
> is that they are biased to perform a specific separation between
> concerns that cannot be applied on the web AS IS!

I don't think this last statement is correct. For example MVC has been
successfully applied to Web application frameworks by Apple WebObject's
since 1996. Check out their latest documentation:

http://developer.apple.com/techpubs/webobjects/DiscoveringWO/index.html

Or a rather outdated documentation for WO 2.0 I think, but more technical
and perhaps easier to grab the concepts from, which is available at:

http://www.crust.net/resources/w3/webobjects.html.d/WebObjectsDoc/

Apple, or NeXT at that time, used to sell this stuff for really big bucks
(I'm talking about $50k/license), and they had large customers like Fedex
and Disney Interactive. Of course, WebObjects was much more than that, they
had, and still have, a very nice, fast and productive DB <-> objects mapping
tool.

> Now you could ask me: what is the best SoC model for the web?
> 
> How do I know!?!
> 
> I would be *very* egocentric from my side to say: look, you should
> decouple your application like this and this and this. How do I know?
> 
> The only think I think I can safely say is: identify your concerns and
> work to separate them.
> 
> In some cases, you might even find that MVC is perfect for the job.
> Great, use it. But that's the difference between Cocoon and the rest of
> the world:
> 
> 1) Cocoon is about applying SoC on the web
> 
> 2) the others webapp frameworks are about applying MVC on the web
> 
> Since MVC is a very specific implementation of the SoC metapattern, you
> should be using those MVC-based frameworks only when MVC is good for
> you: unfortunately, not many times since it forces you to follow
> patterns that weren't invented for the web.
> 
> So, I think you now understand why
> 
>> MVFC: model, view, flow, controller... :-?
> 
> is a terrible idea: the concept of flow partially overlaps with the
> concept of controller. But 'flow' is more at the application level: you
> wouldn't be able to state the flow of a GUI widget, but you would be
> able to describe the flow of photoshop operations in terms of different
> widgets.
> 
> See my point? MVC works well on small and defined components, but the
> web component (a page) is too small. We need to find something else, for
> example:
> 
> - pipelines
> - business logic
> - transitions
> 
> but I won't even start to discuss this since I know that each one of us
> will have a different opinion on the subject.
> 
> Just one thing: let's stop citing MVC as a good practice for web
> development. It's not, let's fact it once for all and move forward.

As I said above, I do think MVC makes a lot of sense for the Web world. I
think Cocoon has the right ingredients to make it a really nice and powerful
MVC framework for building Web apps. We just need to see what is the right
mix and recipe for all these ingredients to make a good cake ;)

Best regards,
-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org