Armin Michel wrote:
>
> IMHO, facades are only useful when they do some extra-work, e.g.
> consolidating the work with many other EJBs.
>
> When you just use a facade to plainly forward any request to exactly one
> EntityBean (1:1 relationship between facades and EntityBeans) than it's not
> worth the trouble.
Except if there's a need to keep the design uniform. I am always using a
following layered architecture in my J2EE applications:
+---+---+ +---+---+---+
| P | I | | S | D | P |
| r | n | | e | o | e |
| e | t | | r | m | r |
| s | e | | v | a | s |
| e | r | | i | i | i |
| n | a | | c | n | s |
| t | c | | e | | t |
| a | t | | | | e |
| t | i | | | | |
| i | o | | | | |
| o | n | | | | |
| n | | | | | |
+---+---+--+---+---+---+
| Framework |
+----------------------+
Presentation and interaction layers are deployed on web container.
Presentation layer contains HTML, WML or XML specific code (e.g. JSP tag
extensions). Interaction layer contains MVC command classes and
presentation related model components. The rest of the tiers, service,
domain and persistence are deployed on EJB container. Service tier,
implemented as session beans, provide the use case implementations and
serves them as a facade to the interaction tier. Domain layer contains
CMP entity beans and dependent objects. Persistency tier contains
possible data source specific code. For instance BMP entity beans. The
framework package contains some common classes used everywhere. I
usually deploy the framework jar file to ${JAVA_HOME}/jre/lib/ext.
The good thing about this architecture is that it is easy understand
even complex use case realizations since every use case follow exactly
the same design. The bad thing is that it requires some extra code (and
an extra EJB call) when doing simple things (like mentioned in previous
mails). But I later hope to resolve this extra programming overhead by
using code generators.
--
Joni
[EMAIL PROTECTED]
