Re: Any knowledgeable Object -> Relational coders in here?
От | James Robinson |
---|---|
Тема | Re: Any knowledgeable Object -> Relational coders in here? |
Дата | |
Msg-id | 1995360A-3CB1-11D9-9AEC-000A9566A412@socialserve.com обсуждение исходный текст |
Ответ на | Re: Any knowledgeable Object -> Relational coders in here? (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: Any knowledgeable Object -> Relational coders in here?
|
Список | pgsql-jdbc |
Hibernate looks *very* attractive. The trouble is how to get 'there' from 'here', while protecting ourselves from this very same thing again... We were / are an EJB 2.X shop. We're sick to death of, ultimately, 4 different representations of our data: Relational model in PG. We're happy with this layer. We maintain our DDL by hand and have (relatively) clear visions on how to improve our DDL, time permitting. Entity bean model. We use XDoclet to generate our deployment descriptors, so, ultimately, the entity container handles the runtime relational <--> entity mapping. The Entity container caching we see as good, for the most part. But, here's where we're really galled ... DTO model. Can't use those wily Entities outside of the transaction, so you gotta map 'em to plain-old objects, and we (currently) do this by hand. This is done in our stateless session layer, with, ultimately, hand-written code to transfer attributes to (in reader methods) DTOs from Entities and from DTOs (containing just the subset of the data graph which is necessary from said update view) to Entities for update and create methods. Interspersed in the reading methods and the create / updating methods are little fairy dust sprinkles of actual business logic, including row-level authorization checks. It seems that the raw-data-movement code grossly outweighs the truly necessary business-logic code, bloating the codebase and draining resources and our souls in the process. View models. Gotta render those DTOs into web pages and convert HTTP GET / POST params into DTOs. Jython and Velocity (via JPublish.org) are are apparent friends here. OK -- Hibernate would allow us to eliminate the dichotomy between the Entity (persistent object) model and the DTO model. Extremely cool. We've already begun isolating 'knowledge' of Entity bean use to 'within each package only', and each package interacting with other packages only through the session interfaces, so that we could begin to migrate from Entity beans to Hibernate or whatever other seemingly-better persistent object model we deem suits our need best. Questions, though: Anyone take part of projects involving object persistence technology upheaval have any tips to pass down? How to code using Hibernate (or what have you) to prevent us from having things be so painful the next time? EJB's CMR really seduced us into establishing CMR between components in separate packages, and we're going to have to work overtime in order to unravel those icky bonds. But it is ultimately possible. But with Hibernate's seemingly automatic traversal of an object graph at attachment time, is it possible to relatively separate persistence logic across package boundaries? With entity beans, our opinion of the transfer from detached object to persistent object (in the form of the bodies of the updating session bean methods) was that it is *too* explicit -- we gotta write every line, whereas Hibernate might well be too automatic -- the whole thing might run away on us when we reattach a single composite object into the persistent graph. Finally, somewhat related, some views need more data than others (obviously), and some update pages update some data yet not others (duh). When the data needed crosses architectural boundaries, we ultimately end up returning too much information to the requesting session-bean code / view code (which is subsequently ignored). If we were coding in a fewer / no layered mode (i.e. JSP / PHP straight to the database), this would not be an issue since we'd be coding explicit selects with the appropriate joined tables / columns right in the view, and we'd be good to go. But, as the number of layers increase, things seem to ultimately err towards 'return more data to the view' as opposed to 'add more fine-grained methods to the session layers'. Any good patterns to reduce this, or do we just stink? If the data is already cached in the entity layer, this isn't such a big deal, but when the extraneous data read calls result in N+1 round-trips to the database, it gets slow and annoying. And you can only cache so much data... . Ugh. On Nov 22, 2004, at 12:20 PM, Dave Cramer wrote: > Not exactly sure what you are looking for but have you looked at > hibernate ? > > --dc-- ---- James Robinson Socialserve.com
В списке pgsql-jdbc по дате отправления:
Следующее
От: Vadim NasardinovДата:
Сообщение: Re: Any knowledgeable Object -> Relational coders in here?