On 10/6/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> 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.
If by persistance layers you mean things like hibernate and/or ibatis,
I would 100% agree with you. But if you mean that if you have a BL
POJO, say IMessagingService, which uses two DBs (at least logical)
like the user db and the db for messages, and you are acessing the DBs
direct from the BL instead of defining a IUserPersistenceService and
IMessagingPersistenceService and providing DB-based Implementations
for this, than I must say, you are too lazy, and will pay the bill one
day :-)
>
> 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).
I don't see the point. Wouldn't using a
stateless-session-bean-like-Singleton-POJO with a ConnectionPool to DB
(which it manages by itself, or is managed by a central
ConnectioXYZManagementClass, but in backend) ensure the same?
>
> 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.
I'd still consider this not optimal because your actions know things
they shouldn't. And if something knows a thing it shouldn't know, your
system is more complex than it could be. Agreed?
You can't switch from the DB to FileSystem for example without
changing the Actions...
>
> 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).
Well, Rick Reumanns site, which was unfortunately down is last time,
had a good example for that. However it's said to be common rule, that
in a well designed application each layer can only see exceptions from
previous layers.
Example:
Something in the jdbc driver throws an SQLException, like connection
is lost or whatever
The persistence layer catches it, logs it and rethrows a
PersistencePOJOs Exception, like: DB is generally unavailable or
something.
The business layer catches it and rethrows: Persistencelayer is
unavailable (all names are just examples).
This is caught by the action, which then presents it to the user
(which can be done by throwing a presentation-layer exception and
proceeding it with your general error handler) "Sorry, currently we
can't proceed your request, try again later" or whatever.
The good thing about it:
- You don't need to import classes from other layers
- You don't need to care for exceptions you don't understand
(layer-technically, someone who writes an action doesn't care whether
its an SQLException or a FileNotFoundException)
- You can change the implementation of the complete layer without
changes in other layers (like switching from JDBC to JDO or FS, or
like changing from corba to rmi or ejb).
- You still can log at any point (or at all points) and mail and
notification will work even better.
Everything in this mail is just a private opinion :-)
regards
>
> --
> Frank W. Zammetti
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
