Hello all,

I am new to using an Object Relational Mapping Framework to provide
database connectivity. The last large project I worked on was in C++
and we wrote the Persistence Mechanism ourselves - CRUD for a base
class and all Business Objects inherited from this and specialized the
methods to provide DB specific SQL calls. I understand the placing SQL
in the Business Objects is now frowned upon by some and that we
"should" add one more level of abstractions.

Anyway, onto my question. I spoke to an experienced Java consultant
yesterday that we brought in at an exorbitant price. I asked him his
thoughts on using ORM for the project we are working on. He told me
that in his experience he had usual written the classes for database
himself and let the DB take care of issues such as Transactions and
Connection Pooling.

If the DB can do this for you what are the benefits.
* Saving a lot of coding for sure.
* Simplicity in mapping objects to the relational space. ok.

What are the other cons of letting the DB manage this as opposed to
using an ORM? Can the DB provide all the features of the ORM in and of
itself? (We are using DB2 UDB for the IBM iSeries. V5R2)

I'd also like to hear thought on placing the database connectivity
inside the Business Objects.

Any help would be greatly appreciated,

Jason


Jason
jasonu (AT) vsac (DOT) org
Vermont Student Assistance Corporation

Hi Jason,

You wrote:
This sounds rather surprising. I'd say either there has been a miscommunication
or your consultant is not a specialist on databases. What strikes me as
especially odd is his apparent remark that transactions should be left to the
database. If you think about this only a couple of seconds, you 'll probably
realize that transactions (at least the definition of transaction boundaries)
are part of the application logic. As such they can not simply be 'left' to the
database.

I think the same applies to connection pooling, at least in general. I know some
RDBMSs provide a kind of pooling (Oracle MTS for one, but there doubtlessly are
others), but in general the connection pooling is taken care of in the JDBC
layer.

In short: assuming you accurately described your consultant's opinion, I 'd ask
for a second opinion. One other idea might be totry and get hold of a copy of a
book by Martin Fowler on Enetrprise Java patterns. Very insightfull, and he
seems to be saying all the right things about database access. It used to be on
the web as he was working on it, but I suppose it is out now, and you 'll have
to pay for it.

Regards,

Ruud.
--
--------------------------------------------------------------------------------------
Ruud de Koter HP OpenView Software Business Unit
Senior Software Engineer IT Service Management Operation
Telephone: +31 (20) 514 15 89 Van Diemenstraat 200
Telefax : +31 (20) 514 15 90 PO Box 831
Telnet : 547 - 1589 1000 AV Amsterdam, the Netherlands
Email : ruud_dekoter (AT) hp (DOT) com

internet: http://www.openview.hp.com/products/servicedesk
intranet: http://ovweb.bbn.hp.com/itservicemanager
--------------------------------------------------------------------------------------

jasonu (AT) vsac (DOT) org (Jason Us) wrote in message news:<45fe56bb.0311041105.f667405 (AT) posting (DOT) google.com>...

at the end of the day, the database WILL manage transactions if you
need
to write something.

Yet there is one point to take care of
* if you want to have so called optimistic transactions at the
OO code level, you better have an access layer
* if you need pessimistic transactions only - let the database do it
but I've never seen a serious business application that used
pessimistic
locking - read a customer for update - the teller goes have a coffee
and
the databases has that one customer locked all the time while your
user has
a Cappucino at StarBucks :-)

Not using an access layer and writing it oneself is only useful and
better
for very small and simple projects. If you need some arguments, why it
is
better to use some kind of ORM have a look at
http://www.objectarchitects.de/Objec...nceOptions.pdf

Cheers


Wolfgang

"Wolfgang Keller" <wk (AT) objectarchitects (DOT) de> wrote

Apparently, either you do not consider banking serious, or you do not
understand transactions particularly well. Every ATM (and every teller's
terminal) uses pessimistic locking in its transactions.


stenceOptions.pdf

Why do Germans seem so enamored with this crap? Am I imagining it? Or is
there some cultural attraction?

Thanks all. I need to trust my instinct more on these things.

Plus - lots of articles by knowledgeable people have confirmed my thoughts on this.


Jason


"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

Bob Badour wrote:

an ATM is not exactly a business information system... but you're right.
For such short things one should use pessimistic transactions and
indeed I havent seen too many banks who use access layers as most of
them use CICS, IMS or other similar things. Thank you Bob, I didn't know :-)

"Wolfgang Keller" <wk (AT) objectarchitects (DOT) de> wrote


I sometimes spend several minutes at the ATM, and I do not consider that
such a short thing. Of course, the actual transactions are short from the
dbms point of view, but only because someone who understands transactions
well made them that way. My transaction is much longer than the dbms's
transaction.