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
-
Sent via pgsql-jdbc mailing list (pgsql-jdbc@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
|
