Re: Non-ORM layers over JDBC

David Clark wrote:
> If you want JDBC access that is more closely integrated into the language I
> would suggest using Groovy. It REALLY simplifies JDBC access because of
> Groovy's dynamic typing, which is basically the same thing as using variant
> data types in C++, at least syntactically. Groovy's way of executing JDBC's
> statements is also much easier to use. Groovy compiles to Java class files
> and the JVM doesn't know the difference. The groovy runtime/library is just
> a jar file that you stick on your classpath.
>
This app needs to be maintainable by others and rather future-proof, so
I'm a little leery of Groovy as something that's still a bit "out there"
in Java land. I suspect that the best option here is plain old JDBC.
Thankfully the app won't need too much SQL with highly variable WHERE
clauses etc, so it shouldn't be too bad.

I've just spent some time looking over the website for iBatis, though,
and I'd be interested in hearing if anybody has any experience with /
comments about it. It looks closer to what I'm after than hibernate and
friends do.

http://ibatis.apache.org/overview.html
> ORM for me works really well in OLTP situations. If I am doing pure OLTP I
> rarely need to go outside of my ORM access layer, which is Hibernate.
> Hibernate's query language (HQL) has lots of features to make writing SQL
> queries easier and lots of features to minimize performance problems.
Yep, it seems pretty attractive for that sort of role - but not much use
for a 2 tier database app.

I'm trying to keep middleware application servers etc out of the picture
to reduce the number of required components - simplify maintainance and
administration, reduce dependencies, etc.

If I wasn't taking that approach I'd probably just build it in C++ with Qt .
> If you have lots of screens where users are basically building up sql queries,
> using forms, then Hibernate's query by criteria makes this easy because you
> are not longer manually building up SQL (or HQL) queries by hand (which is
> really error prone). All of my complicated search screens use this feature
> of Hibernate.
>
Yep, I truly detest the "Hmm, do I need an AND here" comma-and-keyword
juggling sort of low level syntax fiddling that's required for building
up SQL queries programatically. The query languages offered by things
like Hibernate look nice for that, but Hibernate its self seems to be
designed for use with middleware servers to the detriment of most other
things. I haven't found much good said about its use in "direct"
database apps, though it's clearly great for use in an appserver.

I've also found it more difficult than I thought to plug Hibernate
queries directly into Swing for use as a data model, providing efficient
database fetching etc. Then again, my Java is rather limited as is my
Swing experience, so I might just be doing it wrong.

--
Craig Ringer