Re: JPA and desktop apps

On 23/07/10 20:48, Lew wrote:
> I don't find JPA a problem at all - it's a huge boost. Naturally you
> have to deal with properly setting it up, just like anything else.
>
> If lazy fetching is bad for you, use eager fetching. Simple.

Over potentially limited bandwidth connections where you want queries to
run in a reasonable amount of time? You're kidding, right? Not everyone
is using their app on the local gigabit LAN and doesn't have to consider
the possibility of the user's wifi/cellular connection dropping out.

There's a *huge* difference in bandwidth terms between "fetch customer
id and name" and "fetch all the data in the Customer relation, including
all its child objects like addresses and contact records."

Sure, some things make sense to eagerly fetch, because you expect
they'll get used in most parts of the app. But do you want all their
addressing and contact details every time you fetch them? Even if these
are (as in my case) separate relations accessed by reference, lazy
fetching is still an issue.

JPA offers few if any facilities to hook into lazy fetching to permit

> You need to run DB work on a non-GUI thread if you don't use an ORM.
> How is that different?

It's not. My point isn't that JPA is particularly bad, just that I see
very little advantage for its use in desktop apps in the *real* world.
I'm frustrated by all the currently-fashionable-framework based examples
that show it to be so "easy" and paper over the fact that actually,
making it useful requires a completely different approach.

>> Anyway, since folks here advised me to go for an ORM like Hibernate, I'm
>> curious: How do you handle the need to avoid blocking on database access
>> in your Java GUI apps, while lazily fetching properties of entities to
>> avoid downloading half the database whenever you query it for anything?
>
> Proper design of entities to fit with a proper object model.

Like, say, mapping entities from the database into native Java objects
managed by an ORM?

Isn't that the point?

> Proper separation of view from model, just like if you don't use an ORM.

Sure, that sounds nice. Now, we have this nice pre-made model/view
system in Swing, where all the Swing controls have suitable model
interfaces and are well suited to plugging in your own models.

Let's just use JPA with that existing infrastructure rather than rolling
our own new one. Most of them provide useful mechanisms to drive them
with POJOs, lists of POJOs etc via simple adapters, so they seem an
ideal fit for use with an ORM. Oh, wait, the Swing models aren't
callback/event driven, so you can't lazily load without blocking the UI.
We have to abstract the Swing models, building a model to drive the
model to drive the view.

This is what I'm talking about. Of course you can do it, it just sucks
in terms of productivity. JPA, Hibernate etc can be used on the desktop
in client apps, they're just (IMO) highly overrated. Most people who try
to use them only seem to discover how many problems they leave to the
programmer rather late in the process.

Consider:

http://blog.schauderhaft.de/2008/09/28/hibernate-sessions-in-two-tier-rich-client-applications/

> Methinks you blame the hammer for the carpenter.

Perhaps. Rather, I think this new JPA hammer is just a different kind of
hammer, better for some problems and worse for others. It is rather
overrated as the magic solution to all your database access problems as
it's often touted to be.

In this case, I think it hides and obscures more problems than it
solves. I didn't know that when I started, and want to help others be
more aware of the booby traps in this particular app design, caused
partly by conflicts between JPA blocking-call lazy loading and Swing's
non-blocking event-driven approach to GUIs. It's not that you can't make
it work, it's just way, way more fuss and boilerplate than you'd hope or
expect.

--
Craig Ringer