DTO and VO or NOT synonymous patterns. And both of them are not the same as the POJO's you use with hibernate. While it is possible in a detached state, Hibernate POJO's are not intended to live outside the hibernate session. It is not a java best practice to send your detached hibernate POJO's over the another system. You really should do like a DTO pattern approach to accomplish this. You don't want your data layer from your java application to be tightly coupled to the data layer in your flex application. You also probably don't want to send all properties of such an hibernate object over to your flex application. Or you want certain associations or inheritances to combine in 1 DTO object to simplify the flex data objects you will be working with in your flex application. To solve this problem client-side is in my opinion just plain wrong.
More about the DTO pattern: http://martinfowler.com/eaaCatalog/dataTransferObject.html About the VO pattern: http://martinfowler.com/eaaCatalog/valueObject.html grtz, marcel panse --- In [email protected], "lowdown976" <[EMAIL PROTECTED]> wrote: > > > Just make sure whatever you send through LCDS over the wire is not > > lazily loaded. So load all collection explicitly with hibernate before > > you send them. Or better yet don't send hibernate objects of the wire > > at all, create DTO (Data Transfer Objects; search for DTO design > > pattern) objects instead. Load everything you need in your flex > > application into the DTO and send that over to your flex app. > > > > gr > > marcel > > Or catch the errors and work through the problem, perhaps extending > your collections to solve for the item pending errors. DTO/VO are > synonymous patterns. Half the beauty of using hibernate as a solution > is the potential for lazy loading your object graphs. It >is< most > certainly a flex problem, and can be solved by many different > approachs, as the op's posted solution demonstrates. > > While 'just don't do it' is certainly a simple solution, it is hardly > adequate. I'd love to see a useful response to this, as I am working > through it right now myself. >
