Insuring immutability of objects, where does the responsibility lie?

We have a certain class that is persistable to the database using an ORM Framework (NHibernate).
We don't want to allow updates on this entity once it is persisted. So this class would be updatable only as long as it has not been persisted. So, it seems that this class should expose different behavior to different users or depending on somethin (like the ID) that indicates that the entity has not yet been persisted.

Where does the responsibility to insure that logic lie? Should it be the responsibility of the class itself to insure that no modification to its properties can be made except when the modifier is the ORM?
Or should the user of this class enforce this constraint?
The ORM seems to offer some kind of a solution by allowing us to make the properties immutable (update="false"), thus we can prevent changing an entity at the property level. But is it really the responsibility of the persistence layer to enforce that behavior or should it be pushed to the domain model itself? Even if we allow the persistence layer to handle this, this would not prevent modifications of the object at the business layer level, where a user might modify an object but get an exception when persisting (or even worse, not getting any exception at all, I am still not sure how the ORM handles this).
I think it is pretty obvious that I am kind of lost, so any input is greatly appreciated.
Thank you.


  • edited November -1
    Please see Transactions.
    The application requirements should drive the design decision.
  • edited November -1
    The method save() in DAO level should throw an exception if the identifier is set already, so updates won't be allowed on objects. But to modifying of objects will be still possible while they are not tried to be updated to database. I would suggest to use AOP to catch entities either in service layer or in the very entity. I cannot imagine other ways.