It is often a good practice that instead of directly working with an Entity Bean, we work with a view class of that EB containing all it's attributes. But this way we have already lost the persistancy. So how people could rely on this approach?
Persisting the data is managed by the container which handles the transaction management and database locking. Also, the bean provider will resynchronize the values of any instance variables that depend on the entity bean�s persistent state in the ejbLoad() method and update the DB in the ejbStore() method with any changed data.
Yes I know the persistancy mechanism in EJB. My question is that: Using some ordinary classes as a view to an Entity Bean is considered as a good practice. But this way persistancy will be lost in our application? So why this approach is considered as a goog practice?
Good practice is usually to invoke a stateless session bean method which in turn invokes an entity bean method via its local interface. Why do you think that persistance will be lost in the application?
Yes, it's a common approach. But then Entity Bean attributes are written into a view class which is an ordinary bean class. And from now on this is this ordinary bean which is sent to a remote client(to skip RMI heavy transportation). And my question is here...
I believe avoiding 'RMI heavy transport' involves using value objects to represent Entity beans rather than calling remote methods on each individual bean property...
Where I work, we use value objects for all Entity beans. We leave one method on the remote component interface visible to the client. This method populates the value object with the values of the Entity Bean properties. Then we ship this value object back to the client application where it can invoke 'local' getters to retrieve individual properties.