The default behavior of NHibernate is the write all changes to objects to the database when Session.Flush() is called. It does this whether you want it to or not.
How do we prevent writing bad data to the database when we need to do things like validate business rules or input?
For instance ..
- Customer Name is not null.
- User opens a web browser (without javascript) and deletes the customer name.
- Hits update.
Customer.Nameproperty is updated and ..Customer.IsValid()is called.- Even if
IsValid()is false and we show error messages NHibernate still updates the database.
Best Answer
Specifically for ActiveRecord: if you don't change the SessionScope yourself, AR defaults to a session management pattern of session-per-call, where a new session is created for every operation of ActiveRecordMediator. Thus all objects you retrieve are already disconnected from their parent session once you retrieve them. Changes will not be persisted until / unless you call Save (or SaveAndUpdate, or even Update) which, in a session-per-call pattern, will create a session, attach the object you're saving to that session, call Save, and then dispose the session (causing a Flush and thus the writing of changes).
When you use AR this way, it does exactly what you seem to want (ie no changes are written back unless you explicitly call Save). But this explicitly goes against the expected NHibernate behaviour, and you can't do lazy loading or get much use out of caching. I have used this pattern for some Web apps, but they are designed up-front for eager loading and quite a lot of the persistent objects are effectively immutable and static and can be loaded en-masse at startup time and cached without a connection to any session. If your app doesn't suit this model then session-per-call is probably a bad idea.
Since you seem to be using a UOW pattern, you can't take advantage of this behaviour. Thus you must either evict the object from the NHibernate session (and getting access to the real ISession instance is actually not quite as easy as it seems in AR), or change the way your app works so that properties of persisted objects are not actually modified until after your business rules have been validated.