cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: MVC demistified [was Re: [RT] SpitScript - B-Logic that doesn't suck ]
Date Mon, 24 Jun 2002 21:01:38 GMT


Stefano Mazzocchi 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.

+1

>>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.
> 
> 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...).
> 
> 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!
> 
> Now you could ask me: what is the best SoC model for the web?
> 
> How do I know!?!

hahaha :-)  S**t, I really hoped for an answer, but a good laugh is 
enough for now ;-)

> 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?

Too bad you're not egocentric enough then ;-)

> 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

Yup. The point is that if we want to sell Cocoon, MVC is a cool buzzword...

>>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
View

>  - business logic
Model

>  - transitions
Controller


> 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.

It's a good buzzword, and easy to understand.

I still use it, since MVC is usually correct, even for webapps:
- view=what you see
- model=the data
- controller=behaviour

Even if it's not the case 100% of the time, pipelines are the view.
The model is somewhere in the javabeans-EJBs, and the controller is the 
flowscript.
The sitemap is what ties all together.

So it's a 3+1 model, MVC2 (double level controller).

I know it's kinky, but I'm not joking when I say that *ever* *single* 
developer I met aske me if Cocoon is MVC.

And that when showing flowscript, I hear: "Oh, finally Cocoon has a 
controller!".

MVC is not the answer to all needs, but referencing it can make things 
easier to "market" Cocoon and to make it more understood.


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message