Re: Non-ORM layers over JDBC

[Dave Cramer <pg(at)fastcrypt(dot)com>]

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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc