My tip is simple :
always split presentation and business layers.
Don't mix a large amount of HTML with large amount of handling data in
single class.

Greger skrev:

As with all OO, "Encapsulate the concept that varies."

Encapsulate as much code as possible from knowing that it's running as
a servlet; you never know when you might switch running-environments.

Encapsulate your data layer; don't allow most of your code to know
anything about the database.

Encapsulate your output formats: XML is flavour-of-the-month but
nothing lasts.

Secon Mladen's recomendation and further propose looking into MVC;
browse here:
http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs100.html

Think concurrency and serialisation from the beginning, they're a pain
to retro-tweak.

Finally, if you're going J2EE, then you'll need to read a lot more than
just servlets: start small and build for extension.

.ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html

Quick one - dont make use of static variables in servlets.

Remember that servlets are single a instance with multiple threads and
your app will work wonderfully during development but you'll get very
interesting and incorrect results during testing.

Greger <boss@gregerhaga.net> said:

Some comments on transferability;
- don't hardcode the deployment directory path into your application
 - better yet, don't assume that your application is deployed as
   a directory hierarchy -- use the documented interfaces for referring
   to resources within your web application
- avoid hardcoding any external directory paths (or URLs, for that matter)
 into your application
 - pass information on external dependencies as some kind of configuration
   variable (system property could be a good way to point to
   a configuration file, which then contains data for all external
   dependencies)
- use JNDI and container-provided pooling for obtaining database connections
- don't hardcode the application deployment name (context path) into
 the application; retrieve it dynamically when/if needed; oftentimes,
 the application code shouldn't need it - there are interfaces for
 creating proper self-referential URLs

... at first, the above may feel like unnecessary burden ("this application
will never be relocated"). My experience is that all kinds of reorganisations
happen (directory structures on servers get reorganised, server names or
IP addresses change, external URLs change, database servers change, ...).
If the application has all kinds of external (or even self-referential)
references hardcoded, each transfer will be plainful. On the other hand,
if the application has always been written as transportable, all these
changes are a breeze.

Transportability also eases developing the application with varying
environments (f.ex. separate development, testnig and production
environments). A transportable application doesn't need any change
when taken from one environment to another (thus, there's no risk
of missing a required per-environment change breaking things).