"ACI Team (Chennai)" wrote:
> hello all,
> someone was mentioning about keeping the business logic in EJB or
> SERVLET , could someone explain more about where to keep the logic to be
> efficient enough.
> i think craig was saying something about having a single servlet for
> the entire appln and that servlet routes the request to the ejb which is
> having the business logic, why can't we have the business logic in the
> servlet itself.
> please explain..
> thanx in advance.
> aciteam
>
I use the "single servlet as an entry point" design pattern, because my entry
point servlet is where I enforce some security restrictions -- and it's easiest to
do them all in one place. Rather than coding a single humongous Java file with
all the logic for all the possible forms, though, I've defined an interface called
Action, like this:
public interface Action {
public void perform(HttpServlet servlet,
HttpServletRequest req, HttpServletResponse res)
throws IOException, ServletException;
}
and the logic for each processing function is an implementation of this
interface. The servlet main logic looks at the request URI to decide which action
class to call (the initialization arguments to the servlet include mappings of
request URI patterns to the implementing Java class names, which are loaded
dynamically). I'm quite used to this pattern, so I'm also a little bit
"constructively lazy" -- I will use it even if I don't really need the centralized
control, because it's familiar and flexible.
This design pattern for the servlet works for business logic stored directly in
the action classes, and also works just fine if the ultimate business logic is
stored in EJBs. The reason is that you still need a few bits of logic (in an
action procedure) to access the correct EJB and delegate calls to its methods with
appropriate arguments).
The decision to EJB or not should be based on fundamental application
requirements. EJBs are somewhat complex, but in many cases they pay you back by
providing functionality you'd never want to write for yourself. Simple
applications may not need them. Efficiency should usually be a secondary
criterion -- but that can vary as well.
Efficiency differences between a single-servlet versus multi-servlet
implementation of your business logic are probably going to be so marginal that it
won't matter. I follow a sort of mental road map when designing applications that
has served me well (in my environment, speed of initial delivery is a very
important issue):
Choose what you like (single-servlet vs multi-servlet, for example) based on how
easy it is to maintain and enhance the application later. Code it fast. Profile
it to find the hot spots, and optimize the performance of those spots. Iterate
this process until it is fast enough (or just throw some more hardware at it :-)
Remember the 80/20 rule -- in this case, the principle is that for 80% of your
code nothing you do will have any material impact on performance, so focus your
efforts on the 20% that really does matter.
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
