Re: JPA and desktop apps
От | Craig Ringer |
---|---|
Тема | Re: JPA and desktop apps |
Дата | |
Msg-id | 4C4E832B.20101@postnewspapers.com.au обсуждение исходный текст |
Ответ на | Re: JPA and desktop apps (Lew <noone@lewscanon.com>) |
Ответы |
Re: JPA and desktop apps
|
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: