Re: JPA and desktop apps
От | Craig Ringer |
---|---|
Тема | Re: JPA and desktop apps |
Дата | |
Msg-id | 4C486BDD.10705@postnewspapers.com.au обсуждение исходный текст |
Ответ на | Re: JPA and desktop apps (Samuel Gendler <sgendler@ideasculptor.com>) |
Список | pgsql-jdbc |
On 22/07/10 14:31, Samuel Gendler wrote: > There's no one good answer to your question, although you've gone a > long way to answering it with this: "while lazily fetching properties > of entities to avoid downloading half the database whenever you query > it for anything." Quite simply, you cannot allow the UI to access > lazily fetched properties if you cannot tolerate the UI blocking while > it loads. Yeah, about what I feared. It increasingly seems you can use JPA in desktop apps so long as you don't want to provide a decent "experience" for the user, or don't mind writing reams of boilerplate proxies that JPA is supposed to remove the need for. > I don't use JPA, but I do use hibernate, and removing the > JPA layer gives me a much richer API for interacting with hibernate. > I can write an HQL query which loads the properties that I know will > be utilized in a particular context, avoiding lazy loading, even > though my mappings support it (look for "join fetch" in the hibernate > HQL docs). The same is possible via JPA. The JPA query language is basically just HQL. It still requires your app to know, in advance, what parts of what objects will be required by what parts of the app. This becomes more of a problem when you don't know what the user is going to do and how they're going to interact with the objects, and you're using reusable components that aren't aware of the nature of the objects they're working with. JPA (and ORM in general, including Hibernate etc) is "sold" on the ability to use plain old java objects that map to database entities, including using them as generic beans with any component or group of components that works with beans. Yet, in reality, that just doesn't work in any case where you need to pass in a large collection of objects, only some of which will ever be examined in detail. You have to load *all* the data for *all* the objects, just in case, or modify the component to add JPA awareness that it's not supposed to need. If you're going to do all that, and have to fight JPA's issues with replacing whole object graphs in the process, using plain 'ol JDBC with directly database-aware components starts to seem like a good idea. I guess I'm just confused about why people seem to recommend using these ORMs in Swing-based desktop apps, when they *REALLY* don't fit the Swing event-driven non-blocking single-threaded programming model. > I can disable lazy loading entirely in my mappings, or > control it via my mappings and ensure that things are fetched in > chunks larger than my UI displays them. When it comes to web services > type apps, which often serialize objects out to a remote client, I use > something like dozer to map my hibernate objects over to plain beans > in my controller via a mapping that only copies the properties I care > about, otherwise every request tends to get a copy of most of the db. > Then the view deals only with the non-hibernate versions of your > objects. Ugh, so you work around the limitation with yet another layer of abstraction / proxying? I get the feeling I'd spend so long building layer after layer to work around limitations that I might as well just write the code that does just what I need in the first place. How do you find your approach as compared to just using JDBC directly? I'm particularly amazed that the NetBeans platform doesn't seem to cover issues with UI blocking. There are tutorials on JPA use with NBP everywhere, but they all just sweep the blocking/reliability issues under the "it's just a tutorial" rug. This gives the poor reader the idea that this might actually be a good idea, leading them straight into a world of pain and suffering. As it is, I'm considering tossing the whole swing/JPA app I have out the window and prototyping something in grails that reuses my existing mappings. It's that or build yet more infrastructure, possibly down to cglib proxies, just to make JPA play well with Swing. Or build a controller layer to proxy for my proxy entities. It's so Enterprise-y, maybe I should do that! *sigh* Enterprise architecture: keeping programmers employed by doing as much work as possible to achieve as little as possible by hiding everything within ten or more pointless layers to work around the artificial limitations of the previous layers. ( I actually have a working system in place for handling lazy loading, dispatching reloads to the database while displaying a busy uI to the user, etc. It's just ugly and very annoying. ) > I always wind up mapping to > non-hibernate objects and then marshaling those, which adds latency > and workload, though this is very unlikely to be noticeable on a > single-user desktop app. Ah, sorry, I may've been unclear. It's very definitely not single user, it has many users interacting with a database over the network. Each instance of the app is single-user, but they all share one database. -- Craig Ringer
В списке pgsql-jdbc по дате отправления:
Предыдущее
От: Achilleas MantziosДата:
Сообщение: Re: PostgreSQL JDBC vs jxDBCon as a model for other language implementations