Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Apache JDBC utils Date: Wed, 2 May 2012 11:16:53 -0700 (PDT) Organization: http://groups.google.com Lines: 69 Message-ID: <17910424.2120.1335982613195.JavaMail.geo-discussion-forums@pbcoq1> References: <3265763.6.1335834184189.JavaMail.geo-discussion-forums@pbph1> NNTP-Posting-Host: 69.28.149.29 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1335982613 13616 127.0.0.1 (2 May 2012 18:16:53 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 2 May 2012 18:16:53 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.28.149.29; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Received-Bytes: 4027 Xref: csiph.com comp.lang.java.programmer:14140 On Tuesday, May 1, 2012 8:57:28 AM UTC-7, markspace wrote: > On 5/1/2012 6:29 AM, Arved Sandstrom wrote: >=20 > > 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 > >> them. >=20 > > 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 >=20 >=20 > Right-o. I knew what Lew meant, but I still found his statement to be=20 > inaccurate. It was clearly an exaggeration to say that dbutils is an=20 > ORM just like JPA or Hibernate. JPA and dbutils are practically on=20 I didn't say "just like JPA or Hibernate". Nor did the OP. > different planets. They solve a similar problem, but they take very=20 > different approaches. >=20 >=20 > > I prefer to differentiate between basic OR mappers like DBUtils that do >=20 >=20 > This is good, I like the term "mapper" here instead of ORM. Data Mapper= =20 > is a design pattern. Specifically it's a lighter-weight one that DAO,=20 > so it's a good fit to what dbutils is trying to accomplish. The "M" in "ORM" stands for "mapping" or "mapper". > > 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. --=20 Lew