DAO design question

[lzwierko]

Hi, I've a general question regarding DAO design. In this case I'm designing DAO basing on Hibernate API, but I suppose same goes for JPA.

public class UserDaoImpl {

	private final SessionFactory sessionFactory;

	public UserDaoImpl(SessionFactory sessionFactory) {
		super();
		this.sessionFactory = sessionFactory;
	}

        public void saveOrUpdate(User user) {
		sessionFactory.getCurrentSession().saveOrUpdate(user);
	}

	public User getById(Integer id) {
		return (User) sessionFactory.openSession().get(User.class, id);
	}

...
}

My question is following: the Session.get() method returns persistant object reference, meaning that any updates on the object will be reflected to database. My assumption was this should be a role of DAO to persist modified objects (thus he saveOrUpdate) method.
In my overall application design I was thinking of passing the domain objects (such as User etc) right down to view part, where they would be modified, and than returned back to business layer and persisted eventually with DAO. Needless say, I don't wan't any implicit database updates upon domain object modification, only explicit save/updates.

I'd really appreciate opinions about this. Am I taking the right approach in this case?
Second question is does it make make sense to use Session.getCurrentSession for queries only? In spring, service calling such dao function would need to be transactional, does that make sense for ueries only

[Marten Deinum]

1) Don't use openSession if you operate on a spring managed sessionfactory, this will open/create a new session outside of springs transaction/resource management. (Which will eventually will give yu some sort of transaction issues, connection iss ues, memory issues).

Hibernate (and JPA also) return managed objects and don't require an explicit update, however if you use them in the view (and don't use a long running transaction) updates aren't persisted without explicitly calling save. If you don't want this make it a detached object, do your updates and save. Drawback is that you will also loose lazy loading, caching etc.

[lzwierko]

Marten, thanks for the reply. So, what you say is that if I want to present the DAO retreived data in the view (and possibly modifiy it) I should *not* us use the retreived persistant object directly, but rather re-pack it to some other object for presentation? And later update the presistant object directly? In such case the saveOrUpdate() DAO methode becomes obsolete as this is only for transistant objects. Is that correct?
In this case, it seems to me that it's more convinient to work on detached objects (as I can use the same beans in all application layers) and always commit them using DAO objects. Can you give me some guidelines on this.
thanks.

[lzwierko]

ok, to answer my own question (for anyone interested): when working in transactional mode, with either spring managed transactions (@Transactional) or manual transactions, using getCurrentSession(), after transaction is closed the bean becomes detached and modifying it does not result in update to DB. So it can be safely used UI or any other application layer. Later to persist it, call to saveOrUpdate() or just update() has to be made.
That's that.