using such "view objects" is a common J2EE pattern (the value object, or data transfer object). I use it extensively in Struts and OJB applications. It helps decoupling presentation/business logic/persistence tiers in your app, and in the case reported by Philippe, avoid an adherence to the PersistenceBroker API, when one would just tie to the ODMG API.
The drawback is that it adds a lot more classes and code to get and set properties in your objects.
So, as usual, the choice between the two alternatives is a matter of compromise between efficiency and maintainability/evolutivity.
Guerrero, Axel wrote:
you're correct as far as the duplicate objects goes... if you name your properties the same in both objects, you can use BeanUtils (part of the commons jar) to save yourself the tedious work of "a.setXXX(b.getXXX)" when copying properties back and forth. I'm also using struts so I have to copy the properties from the view object to the form bean as well
I am also using EJBs and in my case I could be crossing physical boundries as well as logical (EJB servers being in one machine, web servers in another).. so the view objects are serializable as well.
Axel
-----Original Message----- From: Philippe Boisaubert [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2003 11:41 AM To: OJB Users List Subject: Re: Changing object properties outside the transaction ...
I think about it too. But I must have duplicate object which are the same (or contains only the updatable properties) than persistent ones. Another solution will be to use FormBean (I use Struts) but it forces me to pass a form bean (view data) in my persistent method (persistence layer) as an argument and copy properties. It works but I don't think it's very clean for layer separation. I think about cloning object too. But I never try with this solution.
Thanx for the reply.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
