Re: struts using jdbc
Richard Senior wrote:
Having data access code in actions couples your choice of
view/controller framework, i.e. Struts, to your choice of data access,
i.e. JDBC/DAO. Delegating the data access to another layer of code makes
it easier to change your DAO implementation, e.g. to Hibernate, later on
and promotes re-use of your data access code.
JDBC/DAO classes are arguably a better choice than Hibernate.
You bandy about terms like "promotes re-use of your data access code" as if
that were actually possible or beneficial. Data access code is tightly tied,
and inevitably so, to the data model for an application and the logic
performed on the data. This militates against re-use of data stuff, although
I do reuse abstract classes that handle connecting, disconnecting and the
like. But then, I wrote those classes, so they don't suffer the weaknesses an
O-R Moreau creates.
As for switching from an RDBMS direct access to Hibernate, bleah! That's for
people who don't get set algebra and the power of SQL. Every time I've used
one of those "O-R" frameworks I've spent more time and effort fighting its
limitations that I would have done using JDBC and SQL. Having done it both
ways, I feel secure in this assessment.
Object views recapitulate the flaws of the network model database, which lost
to the relational model a couple of decades ago for good reason. (I've worked
on network model databases, too.) Hibernate is a waste of time and energy and
locks you away from the value of SQL.
I change databases on the back end all the time, but that's apples to apples.
I would not trade the power of an RDBMS for the crippling bloat of a
Hibernatish framework.
--
Lew