Hello,
We're using Hibernate POJOs instead of Entity Beans in some places in our architecture. I was wondering, what would be the correct way to create Value Objects.
Is it approapriate to extend a POJO and use that as the value object? For example,
Code:
// POJO
public class User implements Serializable
{
// persistent fields
private String login;
private String password;
// getters/setters
.............
// getters/setters for the Value Object
public getVO()
{
UserVO vo = new UserVO();
vo.setLogin(getLogin());
vo.setPassword(getPassword());
//other fields
return vo;
}
public setVO(UserVO vo)
{
setLogin(vo.getLogin());
setPassword(vo.getPassword());
}
}
//Value Object, and IUser is the business interface
public class UserVO extends User implements IUser
{
}
public interface IUser
{
//list of persistent getters/setters
}
The Value Objects generally contain stale data if EntityBean are used, but with Hibernate they always contain up-to-date data (as we simply extend a POJO) The side-effect of this means that the object is directly mapped to the DB, so setting a property of a value object may eventually alter the record in the DB, which we don't want, as this is supposed to be a value object, not a POJO. How to prevent this from happening?
Maybe, I shouldn't worry too much about this, as VO is not actually mapped to the DB, although POJO is. And once VO is not mapped, ti should be no problem changing its properties.
In which cases and under which circumstances will DB get updated if the client is using the VO?
Anyonce could shed some light?
Login
FAQ
Search
