似乎正确的方法是在构造函数中实例化ISession和ITransaction,然后在析构函数或Dispose()方法中进行处理.
当然,如果有人调用Save()方法,那么ISession将被刷新并且ITransaction将完成,因此在调用Save()之后,将再次没有有效的打开事务来保存()…除非我提交了第一笔交易并立即开通了另一笔新交易.但这是个好主意吗？
在设计方面,做一个提交操作是有意义的,但我不一定能控制代码,而其他开发人员可能不太遵守UnitOfWork模式.
通过尝试使UnitOfWork容忍每个会话的多个事务,我会失去/获得任何东西吗？我应该检查一个打开的事务,如果它已经被提交则抛出异常,而不是进行新的事务吗？
解决方法
是个好主意吗？这取决于.
问题是第一个事务中的数据更改将被提交,而不确定整个工作单元(会话)是否在最后提交.当你得到一个稍后的事务中的StaleObjectException时,你已经提交了一些数据.请注意,这种异常使您的会话无法使用,无论如何您必须销毁它.然后很难重新开始并再试一次.
我想说,在这种情况下它运作良好：
>这是一个UI应用程序
>更改仅在最后一个事务中刷新.
UI应用程序
错误由用户以交互方式处理.这意味着用户可以在错误的情况下查看实际存储的内容并重复他所做的更改.
更改仅在最后一个事务中刷新
由NH实施的会话仅在最后或“必要时”刷新更改.因此,在会话提交之前,可以保留内存中的更改.问题是NH需要在每次查询之前刷新会话,这很难控制.它可以关闭,这会导致副作用.在编写简单的事务时,您可以控制它.在复杂的系统中,几乎不可能确保没有任何问题.
简单方法(tm)
我编写了一个非常大的客户端 – 服务器系统的持久层.在这样的系统中,您没有用户直接处理错误.您需要处理系统中的错误并以一致的状态将控制权返回给客户端.
我将整个事务处理简化为绝对最小化,以使其稳定并且“白痴证明”.我总是创建一个会话和一个事务,它会被提交或不提交.
