Re: Apache JDBC utils
On Tuesday, May 1, 2012 8:57:28 AM UTC-7, markspace wrote:
On 5/1/2012 6:29 AM, Arved Sandstrom wrote:
On 12-04-30 11:27 PM, markspace wrote:
If the authors of the projects say it's not ORM, I'll choose to believ=
e
To an extent I'm happy to go with what authors say also. More precisely
DBUtils *is* an ORM - just look at the available ResultSetHandler
Right-o. I knew what Lew meant, but I still found his statement to be
inaccurate. It was clearly an exaggeration to say that dbutils is an
ORM just like JPA or Hibernate. JPA and dbutils are practically on
I didn't say "just like JPA or Hibernate".
Nor did the OP.
different planets. They solve a similar problem, but they take very
different approaches.
I prefer to differentiate between basic OR mappers like DBUtils that do
This is good, I like the term "mapper" here instead of ORM. Data Mapper=
is a design pattern. Specifically it's a lighter-weight one that DAO,
so it's a good fit to what dbutils is trying to accomplish.
The "M" in "ORM" stands for "mapping" or "mapper".
<http://martinfowler.com/eaaCatalog/dataMapper.html>
<http://rrees.wordpress.com/2009/07/11/the-dao-anti-patterns/>
By "monolithic" I mean, in the case of JPA, creating one data-access layer =
which sits between all object code and all DB access. Using a single 'Entit=
yManager' to handle many things for a long time is monolithic, and causes p=
ersistence sessions to fill and get slow. Funneling everything through a si=
ngle data-access construct suffers from the "God object" complex.
"Non-monolithic" means, for example, a separate data-access class for each =
module that needs access. So your "FooOrder" module will have a data-access=
object with its own 'EntityManager', "BazHistoryMarker" will have another,=
and so on.
This makes data access easier to reason about and to troubleshoot. It also =
obviates various run-time problems.
As for "lightweight", I have only heard, "not many API calls" as a metric. =
How does dbutil rate as lighter than JPA by that metric? Even the short sni=
ppet posted here of dbutil code looks messier and harder to set up than JPA=
..
JPA is the first ORM (sorry, folks, dbutil is an ORM) I've found worth usin=
g. I avoid Hibernate's JPA because it's too easy to slip into pre-JPA idiom=
s with it, which in my view ruin its utility when you do.
JPA has shown itself the leanest (in terms of programmer effort) and slicke=
st way to handle its intended use cases (e.g., not bulk inserts) of anythin=
g I've tried.
Unless it's abused horribly, which I've also seen. But the abusers of JPA a=
re no better with JDBC, other Java idioms, and I predict nor with dbutils.
--
Lew