General talk about software patterns

[oleg shteynbuk <oshteynbuk AT nyc.rr.com>]

I believe that Sun and Apache when first mention this pattern refer to 
it as a Model 2 that is a variant of the MVC pattern but probably 
because Model 2 doesn't sound as good as MVC they use MVC most of the 
time. My first impression was similar to yours, where is the 
notification part of MVC. There was a discussion on this issue, I do not 
remember if it was on apache site or sun's or in some book, that if you 
are the MVC purist then it is not MVC but if you are not a purist then 
it is an MVC variant. And actually the MVC structure is there but 
behavior is different, does it qualify it is a variant is a separate 
question. Model 2 probably sounds more like sun's internal codename and 
not a pattern name but it is used too.

oleg


Cruz Farfan wrote:

> Hello everyone,
>
> I apologize if you already receive this email. I sent it to the 
> siemens-patterns mailing list, but didn’t get a lot of feedback. I’ll 
> really appreciate your comments. This was the original message:
>
> Most Java experts recommend applying the MVC pattern to design J2EE 
> applications. However, the examples they show don’t seem to follow the 
> MVC pattern of Smalltalk and the first POSA book. In that book, the 
> “Siemens” group describes a change-propagation mechanism as a 
> fundamental step to write an MVC-based application and suggests the 
> Observer pattern to implement such a mechanism. That element is seldom 
> present in J2EE applications because is too expensive to implement in 
> terms of performance. In addition, Views and Controllers components 
> are bundled together in J2EE applications as in the Document-View 
> variant of MVC. Because of that, a group of people in the pattern 
> community has suggested that really what J2EE applications are 
> implementing is the PAC pattern, but I also have my doubts about that. 
> Certainly, the Presentation component ! of PAC is a bundle of the View 
> and Controller of MVC, but PAC defines a hierarchy of top, middle, and 
> bottom level cooperating agents. Each agent consists of its own 
> Presentation, Abstraction and Control components. In fact, the 
> political elections example in the POSA book implements a pie chart as 
> a view for MVC and as a bottom-level agent for PAC. Thus, a simple 
> agent like a pie chart consists of its own Presentation, Abstraction 
> and Control components. Although this is closer to J2EE architectures, 
> the notion of the hierarchy of agents is not. Of course, one can argue 
> that the hierarchy is implicitly present, but I think this is forcing 
> things to fit in place. In contrast, J2EE architectures seem to follow 
> the mu! ch simpler Layers pattern. A minimalist example could be the 
> following three-layer architecture:
>
>    1. Presentation Layer (JSP, HTML, etc.)
>    2. Control or Mediator Layer (Servlets, Session EJB, etc.)
>    3. Abstraction or Model Layer (Entity EJB, JDO, etc.)
>
> I’m using the same PAC terminology on purpose because I realized that 
> one can see the whole J2EE system as one big PAC agent, but I’ll still 
> argue that most J2EE applications follow neither MVC nor PAC, but the 
> Layers pattern.
>
> Your thoughts?
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Free online calendar 
> <http://us.rd.yahoo.com/mail_us/tag/*http://calendar.yahoo.com> with 
> sync to Outlook(TM).