Hi,

I'm studying NHibernate a bit, and I wonder why ISession and ITransaction are separated.
I see that the Session has a reference to the transaction (if any) that has been started on this session, but I wonder what the added value is of separating those two.
Why did the NHibernate designers/devvers opt for this, and why didn't they choose for 'combining' these 2 classes into one ?

NHibernate is a port of Hibernate (so they have the same design).

AFAIK, Sessions and Transactions are not coupled together because you can use a session without creating a transaction and you can create many transactions (one at a time) through the life of a session...
And they have differents functionnalities so it is probably a good design to keep them separated.

Indeed, they have different responsabilities.

However, if a transaction object would not be visible outside a session that would not be problematic.
As far as I know, you cannot have multiple transactions that are 'alive' at the same time, if the share the same connection.
If you use a session, without using a transaction, it would also not be a problem: the transaction object is just encapsulated into the session object.

I think, it will keep the api simpler if these 2 objects 'were put in one class'.

The Session object would then have a StartTransaction method (like it has now), but it would also have a commit and rollback transaction.
This would not be a problem if 'paralel transactions' are not supported. However, if you have a database, which allows nested transactions, it can be a problem.
(AFAIK, the SqlClient and OleDb providers do not allow you to start a transaction on a connection, if another transaction was already started on that connection).


note: I'm not critizizing the design of hibernate; I'm just thinking and wondering.