Re: Non-ORM layers over JDBC - Mailing list pgsql-jdbc

On 24-Mar-08, at 1:40 PM, Craig Ringer wrote:

> 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 think groovy is going to have considerable staying power.
> 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
>
> -
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc