General talk about software patterns

[Cruz Farfan <cruzfarfan AT yahoo.com>]

Thanks for your reply Clint.

 

That's an interesting way to see the problem, but I see some issues with it. First, MVC is not a pattern for GUI components. It's a pattern to separate some data abstraction (model) from its user interface (views and controllers). Second, although I agree you could do a lot with JavaBeans, most people use them within GUIs and use Servlets and EJBs for business logic. Thus a JavaBean as a MVC Model is not really a recurrent pattern. Finally, you didn't mention the change-propagation mechanism of the classic MVC. Which normally Java developers don't implement in Web applications because is to costly performance wise.

 

What I'm trying to do is identifying the pattern that's implemented in most J2EE applications. Most frameworks teams (Struts, Expresso, etc) say is MVC. Other researchers believe is really PAC.

 

Your email made me think that maybe the PAC followers are also thinking in just the "Presentation" Layer. Which means they could be applying PAC at several levels and ending with Layers at the end. I will investigate more this new idea.

 

Thanks again,

 

Cruz Farfan

Clint Shank <clintshank AT hotmail.com> wrote:

> MVC is an architectural pattern for GUI components. When applied to J2EE, 
> you need to look at the presentation (web) tier only, not all the tiers. 
> The MVC pattern for J2EE web components looks like this:
>
> Controller: Servlet(s)
> View: JSP’s, HTML, etc.
> Model: JavaBeans
>
> The servlet is the controller. It determines which javabean to use to 
> handle the business logic, and which view to select to display the result. 
> The JSP’s contain only view logic. That leaves the JavaBeans as the model. 
> The JavaBeans can do all the work, like contain all the business logic and 
> make JDBC calls, or they can just delegate to EJB’s.
>
>
> >From: Cruz Farfan 
> >To: gang-of-4-patterns AT cs.uiuc.edu, patterns-discussion AT cs.uiuc.edu
> >Subject: [gang-of-4-patterns] MVC, PAC or Layers in J2EE applications?
> >Date: Mon, 9 Jun 2003 18:!
>  05:18
>  -0700 (PDT)
> >
> >
> >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 
> &gt!
>  ;this is
>  forcing things to fit in place. In contrast, J2EE architectures 
> >seem to follow the much simpler Layers pattern. A minimalist example could 
> >be the following three-layer architecture:
> >
> >
> >
> > Presentation Layer (JSP, HTML, etc.)
> > Control or Mediator Layer (Servlets, Session EJB, etc.)
> > 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).
>
> _________________________________________________________________
> The new MSN 8: smart spam protection and 2 months FRE!
>  E*
>  
> http://join.msn.com/?page=features/junkmail
>
> _______________________________________________
> gang-of-4-patterns mailing list
> gang-of-4-patterns AT cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns

---

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