Thanks for the reply Chris.
I agree with your comments, I don't think a J2EE application follows the classic MVC pattern, but what about PAC (Presentation-Abstraction-Control)?
In: Enterprise Java Programming with IBM WebSphere (Brown, Craig, etc.) the authors suggest that "generalizing" the concepts of PAC leads to a Layered architecture. Certainly, if they considering all the agents in one level as a layer of the architecture, I can how of the set of agents will form the layers. However, if they're considering Presentation, Abstraction and Control as the layers of the architecture then I would disagree because in PAC you should have those components present in each agent. The fact that in the book they don't mention the agents at all makes me think they were leaning more towards the second alternative.
Am I wrong in that appreciation?
Also, you mentioned there's literature about this subject. Could you recommend me some titles?
Thanks a lot,
Cruz Farfan
Chris Gerrard <[EMAIL PROTECTED]> wrote:
I agree that the J2EE Model 2 architecture is not a classic MVC architecture, and so does most of the serious literature.
I think there are two major reasons for this:
First: the "usual" application discussed in the J2EE world is a browser-based Web app that is ill suited for the change-propagation characteristics of the original Smalltalk-80 MVC architecture. It's simply too awkward/expensive to introduce mechanisms into the Web/browser mechanism to auto-update the browser with model changes.
Second: and virtually unrecognized in it's obviousness, is that the vast majority of J2EE "applications" are not applications of the same "type" as MVC applications. By this I mean tha J2EE apps are not behaviourally rich interactive UI-based applications with a complex model coupled to a complex UI within an event-driven interactive model with multiple simultaneou! s views of the model that need to be synchronized. Instead, J2EE applications are really very thin veneers that serve as database publishing mechanisms with very little internal complexity - in essence they're mere conduits that server to translate incoming HTTP requests, sometimes containing forms with data, into SQL queries, retrieving the results of those queries, and then rendering them in HTML et.al. for a shove out the pipe to the browser.
This is one of my great disappointments in the Java/J2EE space. That the mere mention of creating true, rich "applications" (in the classic sense) universally receives the same response: "You can't do that! How will we keep the database pure unless everything that happens happens 'in the database'..." and such like exclamations. One of my favourites is the claim that building "real" applications, with the relevant model information present within the app space and therefore amenable to the classic application architecture and! design concepts will result in the existence of far too many objects, inevitably exceeding the ability of the machine to support them (so don't even bother); and this without a shred of evidence to on the effect of large business object (model) populations.
sigh...
S, in short, I agree that the Layers pattern, albeit a more general pattern than MVC, is more accurate. But it doesn't have the cachet of "MVC" does it?
I also believe that the common J2EE DB-publishing app architecture should have it's own pattern, and would be happy to help elucidate it, if anyone's interested.
Whew. Sorry about the rant.
Chris Gerrard
At 04:04 PM 6/8/2003, Cruz Farfan wrote:
Hello everyone,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
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 tha! t 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 <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />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 pat! tern. A minimalist example could be the following three-layer architec ture:
- 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?
Cruz Farfan
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).
