Design Patterns discussion

["Clint Shank" <clintshank AT hotmail.com>]

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 
> <cruzfarfan AT yahoo.com>
> 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 
> 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 FREE*  
http://join.msn.com/?page=features/junkmail