Re: JPA and desktop apps
От | |
---|---|
Тема | Re: JPA and desktop apps |
Дата | |
Msg-id | e10739ad5d03f8985bc47f200d3fb0eb@smogura-softworks.eu обсуждение исходный текст |
Ответ на | Re: JPA and desktop apps (Samuel Gendler <sgendler@ideasculptor.com>) |
Список | pgsql-jdbc |
JPA isn't wonder solution, it's works very good if you know it exactly and know implementation of JPA you will use. Then when you create your business logic and database structure it can be optimized for JPA. If you would like to go from legacy databases it can be sometimes impossible (there can be problems with composite primary keys, working as parts of FKs), but I saw one interesting way - create entities without references. This means if A references B, then don't make reference, but just put in A property bId, and then on demand load by findById(,a.getBId()). Generally JPA isn't good for desktop applications, this is due to transaction context (it can work without transactions, ofc), and on demand loading. I use following way to speed up application. 1. First I create services for store/load. 2. For load I create search objects, that contains, if in need, configuration parameters, from point of view of usage of searched objects. Eg. UserSearch {nameLike ='%', wantGroups = true} 3. In this way service class can optimize read operations. When I don't use eager fetching, I commonly use something like this or LEFT JOIN FETCH, depends on configuration and provider for (user : users) if (user.groups.size > 0) users.groups.get(0); this will pre-cache entities. 4. You need always refer to JPA provider implementations, for special configuration parameters, query parameters, or additional annotations (this will make application less portable, but difference between JPA providers are sometimes such big and on such basic things, that portability is fiction, unless your queries will be "SELECT a FROM A a"). 5. Use in queries LEFT JOIN FETCH, don't use eager loading unless objects are in composition. 6. Build queries in dynamic way. This will allow you to change query depending on search specification given in 2. 7. Treat JPA much more like read / write mapping to database, instead of "make everything" utility. Generally make service layer in your application and build specialized facades in this layer for complicated methods. Regards, Radek P.S. I works long with JPA through Hibernate and Postgresql, I still getting bugs and "surprises".
В списке pgsql-jdbc по дате отправления: