Java Reference
In-Depth Information
as opposed to sending them to a dozen simultaneous classes
(or
letting
them
read
a
dozen
books),
which
can
be
overwhelming.
Also, iterative development of each application layer fosters
the application of appropriate patterns and best practices. If
you begin with the lower layers of your application and apply
patterns like Data Access Objects and session facades, you
should not end up with domain logic in your JSPs and other
View objects.
Finally, when you develop in thin vertical slices, it makes it
easier to start early in performance testing your application.
Delaying performance testing until the end of an application
development cycle is a sure recipe for disaster.
Leverage Java EE capabilities
Commit
to
building
real
Java
EE
applications
that
truly
leverage Java EE function.
One of the most disturbing things we've seen more than once
is an application that claims to "run in WebSphere" but isn't
really a WebSphere application. We've seen several examples
where there is a thin piece of code (perhaps a servlet) in
WebSphere Application Server and all of the remaining
application logic is actually in a separate process; for
example, a daemon process written in Java, C, C++ or
whatever -- but not using Java EE -- does the real work. This
is not the recommended approach. Virtually all of the
qualities of service that Application Server provides aren't
available to such applications. This can be quite a rude
awakening
for
folks
that
think
this
is
a
WebSphere
Search WWH ::




Custom Search