Milt Epstein wrote:
>Another rule of thumb for servlets is that you should think of them as
>a web gateway to an application, and only things that are part of that
>request/response transaction should go there -- and anything that's
>more inherently part of the application shouldn't go there.
Perfect. You hit the nail on it's head. Another point to note is that if a
particular functionality (or business logic) is used only in that particular
servlet, keep it in the servlet. If that functionality is also needed in other
servlets then make a seperate class for that and you can use that class in all
the servlets that need that funactionality.
Sanjesh
> On Thu, 10 Aug 2000, Tim Stoop wrote:
>
> > Hi people,
> >
> > While working on my own project, I encountered some (minor) issues
> > that I would like some advice on. The "problem" is this: When I make
> > a program that has several functions, but only one is directly a
> > servlet-function, is it more efficient to just point to other
> > classes (so no servlets) or better to make all the programs that are
> > connected (in a chain) servlets? What are the pro's and con's? Can
> > someone give me some clear examples on what to use when??
>
> Here are some very rough guidelines, not clear examples :-).
>
> To be practical, I'd say it depends on the context of the project
> you're doing. If this is just a one shot deal, a relatively small
> project, one not likely to get a lot of traffic/usage, and the
> auxiliary functions you mention aren't to be used elsewhere (e.g. in
> other servlets or applications), then it's probably OK to throw it all
> in there. That will likely be the most efficient performance-wise.
>
> On the other hand, if this is a large project, long-term with a lot of
> maintenance/updates, it will see a lot of traffic/usage, and/or the
> auxiliary functions may/will be used elsewhere, then you probably want
> to spend more time designing things, which will likely mean more
> modularity and keeping things separate that don't belong together.
> This may not be as efficient performance-wise, but it has advantages
> in terms of maintenance, scalability, robustness, etc.
>
> Personally, I'd very rarely go with the former approach, preferring to
> try to set things up modularly even with relatively small projects.
> But sometimes that can be more tedious, and you have to be practical.
>
> Another rule of thumb for servlets is that you should think of them as
> a web gateway to an application, and only things that are part of that
> request/response transaction should go there -- and anything that's
> more inherently part of the application shouldn't go there.
>
> Milt Epstein
> Research Programmer
> Software/Systems Development Group
> Computing and Communications Services Office (CCSO)
> University of Illinois at Urbana-Champaign (UIUC)
> [EMAIL PROTECTED]
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
