Re: Is it bad to connect to a database via an applet?
Arne VajhQj wrote:
Yes. It is bad to let the applet talk directly to the database.
applet----(HTTP)----web app----(JDBC)----database
is better.
See my reply to your other post for details.
jmDesktop wrote:
Is that middleware piece a "servlet"?
A best practice is to use a layered architecture. Arne illustrated one with
three basic layers: front end, middleware logic and back end data system.
Refinements of the scheme might split middleware into control logic
("Controller"), presentation logic ("View") and business logic ("Model"), for
example. The business logic might communicate to the data system via a
connection layer, such as a Java Persistence API (JPA) framework (TopLink,
Hibernate, OpenJPA).
How many layers you architect, and how thick or thin each one is, depends on
the needs of the particular project. Three layers seems the minimum, more
than seven would be suspect.
The separation of model, view and controller (the "Model-View-Controller" or
"MVC" architecture) has many advantages for robustness, correctness,
stability, maintainability and expandability. This is a case of the principle
of separation of concerns - each layer has a narrow focus of responsibility
and clean, simple ways of communication with its nearest neighbor layers (and
no others).
A Java Enterprise architecture would use JSPs or XHTML pages for the
presentation artifacts, quite likely script enhanced. A framework like Java
Server Faces (JSF) provides the interface components, also controller and
presentation logic components. A custom or framework-provided servlet (or
small set of servlets) provides the glue that ties those front-end components
to the business logic components. There might be specialized communication
libraries to carry messages between layers, such as web-services frameworks or
message queues. The business logic comprises Java components variously
realized as POJO (likely JavaBean-ish) classes or Enterprise JavaBeans (EJBs),
which are not the same as non-Enterprise JavaBeans. They handle things like
coordination of authentication, stitching together requested data into
meaningful structures and so on. Business logic can represent entities, the
nouns of the application domain, or processes, the verbs of the domain.
Business logic connects to the data layer, data layer talks to the datastore,
oh, oh, dem bones.
I just made it sound complex, and it can be if the requirements are big
enough. It doesn't need to be. Simple web apps use XHTML/JSPs/JSF/scripting
for the front end, a little bit of servlet controlling things, Java objects
handling business logic, JPA framework, PostgreSQL or Derby (JavaDB) on the
back end and you're good to go.
--
Lew