> From: The elephantwalker [mailto:[EMAIL PROTECTED]]
> You will find that if you want the _enterprise_ features offered by
> with
> straight jdbc calls, your classes for jdbc calls will be slower than
> and _much more_ difficult to develop.
> I am not a smarter developer than Karl or Magnus. Their algorithms for
> caching, transaction management, pooling (connection, threads,
> you
> name it), are among the best in the business. If I were to _attempt_
> reproduce these features, I would certainly _fail_ to reproduce these
> features in a reasonable time.


Connection pooling and transaction management are provided to session
beans through the data source.  No CMP or entity beans necessary.
Furthermore, if you want sane transaction demarcation, you already have
to wrap all your entity bean access in session bean methods.

Entity bean caching I have found to be remarkably useless.  First of
all, it depends on a pessimistic locking strategy, which is both hard to
use (gotta love those deadlock exceptions!) and not applicable to a
clustered environment or any environment in which the database table can
be modified from an external source.  Furthermore, finder methods are
not cached - and with an eager loading strategy, I really have to wonder
what the great advantage of the caching is... bringing all the bean data
back usually isn't that much more expensive than bringing just the PK
data back, and if it is (because of large data fields) then your cache
is going to have size problems anyways.

Irrespective of who may be a smarter developer, I can guarantee you that
I know a *lot* more about *my* specific business logic than Karl or
Magnus.  Furthermore, Karl and Magnus are for the most part just
implementing a specification produced by a committee of labcoats
dedicated to a lowest-common-denominator set of features that IBM, BEA,
Borland, Sybase, & the rest of the implementers can agree to.  The
absence of ORDER BY in EJB-QL and the lack of a standard PK generation
mechanism make me seriously wonder if any of the people writing the EJB
spec have ever used it to implement a real-world application.

> There will always be a place for jdbc in an enterprise application.
But in
> an enterprise application where the transaction is as important as the
> data,
> and the data structure itself may change from time to time, cmp ejbs
> the
> way to go.

Entity beans can be useful for modeling your data.  For some business
cases, they might actually be all you need.  I, however, have yet to see
one of those cases in the real world.  I will reiterate the three
failings I mentioned before:  you cannot model relationship attributes,
you cannot perform aggregation queries, and you cannot query for data
that spans multiple objects.  I'll add that if you're restricting
yourself to EJB-QL, you're going to have even bigger problems, like the
inability to order the result set without sorting yourself in Java.

Relational databases have evolved over the last thirty years to provide
us with a very refined solution for storing and accessing enterprise
data.  Entity beans are a big square peg that can only be brutally
forced into the multifaceted hole that is our problem space.
> A resultset relies on datastructure strings, and are closely coupled
> the underlying database structure. All my experience indicates that
> datastructure will change many times during a project, after the
> is
> finished, and before the application is retired.
> jdbc is tightly linked with the datastructure. This link goes to a low
> level, as many text strings need to be modified when the datastructure
> changes. Arrrrrgh! Don't get caught in the performance trap where you
> application performance increases by 2%, but its almost impossible to
> change
> your application without competely rewriting it.

If the primary argument for using entity beans is that they offer a
layer of indirection so that you can rename columns, there are plenty of
alternative approaches which are *much* simpler.

I'm not saying don't use entity beans (although I would *definitely*
recommend that a team which does not already have a lot of EJB expertise
should avoid them), but I am saying that it is a huge mistake to
consider entity beans your only means of data access.  To use the square
peg analogy again, reduce the size of the square to something that fits
smoothly through the hole, and fill in around the edges with other
mechanisms (like JDBC).
Jeff Schnitzer
Consulting & Contracting - J2EE, WebLogic, Orion/OC4J

Reply via email to