Leon Rosenberg wrote:
Well you shouldn't have anything with Database in the name in your
action, it should be encapsulated in a service POJO.
I'm not so sure about this... I understand the motivation for saying it
and agree with that motivation, but it's a bit to hard-and-fast for my
tastes. :)
As an example, I have one application where there are quite a few
Actions that call on a number of business delegates to perform their
duties. Those delegates are the POJOs you are referring to. If I let
each of them get a database connection on their own, than a particular
user could wind up using a couple of connections per request (or the
developer would have to ensure that each delegate is used, cleaned up,
including the connection, before the next one is used).
Keep in mind that we aren't using a "real" persistence layer for any of
this, and that would certainly handle such a concern. But many people
are still not using persistence layers, so it's not exactly unusual.
The way we solved this problem is this...
We have a base Action. It performs a number of common functions, one of
which is to instantiate a BusinessDelegateFactory. This factory has the
responsibility for getting a connection through the database (by using a
DatabaseConnectionManager class). Then, the base Action calls an
overloaded version of execute() in the extending Action that has the
factory as an extra parameter.
In the Actions themselves, you will see things like:
ClientBD = (ClientBD)factory.get("CliemtBD");
ArrayList clients = clientBD.getClients();
Doesn't look unusual I'm sure :) The part that is really nice here
though is that if an Action uses a number of business delegates, the
factory ensures that they all share the same database connection. So
we're always only using one per request, which is ideal. Also, the
factory has sole responsibility for setting up and cleaning up the
business delegates, the Action doesn't have to be concerned with any of
that (as it shouldn't).
Is this mixing of layers or otherwise a bad design? I'm not arguing
it's the best thing ever done, but I don't see it as bad either. The
business delegates still are POJOs, and the Actions themselves aren't
really dealing with the database connection directly, they are
delegating to a class that does that. In fact, the Actions are doing
only what they are suppose to as far as I'm concerned: they are traffic
cops, passing things (data, connections, whatever) between objects that
do the real work.
Incidentally, I use the declarative exception handling as well.
Everything bubbles up to the common handler and is dealt with
appropriately there. No try/catch in the Actions, or the business
delegates for that matter (except where there are exceptions that you
know you can handle immediately, everything else just bubbles up).
Makes for *very* clean code, and from my experience I don't find it to
be any less robust. In fact, the consistency with which exceptions get
handled I think is *more* robust... I log A TON of information, send
eMail alerts and construct a nice page for the user (we take the tact by
the way that an exception should never happen and therefore is probably
not a recoverable situation, so just being as kind to the user as
possible is the goal, as well as making it as easy for us as possible to
track down what happened later).
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
