General talk about software patterns

[Cruz Farfan <cruzfarfan AT yahoo.com>]

Yes, I agree. It doesn't look like MVC or PAC. However, this article by Kyle Brown made me think about Layers as the best match.

 

http://www.awprofessional.com/catalog/article.asp?product_id=%7B9ED7B839-AD49-4E91-9796-C3868AF138B5%7D

 

Also, since you're the third person to remark the "coolness" of MVC; I'm now convinced of that one. :D

 

Thanks a lot,

 

Cruz

oleg shteynbuk <oshteynbuk AT nyc.rr.com> wrote:

> I agree that behavior of controller is different too. After looking at 
> PAC pattern again I can see your point that Module 2 is more close to 
> PAC then MVC but I have hard time seeing it as the Layers pattern. It 
> might be difficult to pin down exact match to existing patterns; after 
> all there were no servlets at the time when POSA 1 was published. Intent 
> of MVC in POSA 1 is close to Model 2 except for the last sentence on 
> change-propagation mechanism. Intent of PAC looks different to me, as 
> you noted there is no hierarchy of agents, but if you reduce hierarchy 
> to one then implementation of PAC is close to Model 2, but it is my 
> understanding that intent is what matters and implementations could be 
> different.
>
>
> Having a cool name like MVC might have played a role too :)
>
> oleg
>
>
> Cruz Farfan wrote:
>
> > Thanks for your reply
>  Oleg.
> >
> > Certainly, the Model-2 variant theory takes care of the notification 
> > issue. However, that's not my only issue. When I read Sun's 
> > description of Model-2:
> >
> > http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html
> >
> > I can't help thinking the Controller servlet they're describing is 
> > acting as a Mediator and not as a Strategy. Thus even by Sun's 
> > description the pattern looks more like PAC 
> > (Presentation-Abstration-Control) and less like MVC.
> >
> > Well, I guess that puts me in the MVC purists list :)
> >
> > Thanks again,
> >
> > */oleg shteynbuk /* wrote:
> >
> > 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:
> &!
>  gt;
>  >
> > > 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 J! 2EE 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
> > > with
> > > sync to Outlook(TM).
> >
> >
> >
> >
>  _______________________________________________
> > patterns-discussion mailing list
> > patterns-discussion AT cs.uiuc.edu
> > http://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion
> >
> > ------------------------------------------------------------------------
> > Do you Yahoo!?
> > Free online calendar 
> > with 
> > sync to Outlook(TM).

---

Do you Yahoo!?
Free online calendar with sync to Outlook(TM).