如何在 NHibernate 事务中使用回滚模式？
我想使用回滚模式进行测试我的服务。这些实际上是管理事务并处理所有存储库访问的逻辑服务，由 Winform UI 调用。存储库使用 NHibernate 进行数据库操作。
鉴于 NHibernate 不支持嵌套事务，它无法在测试设置中开始事务并在拆卸中回滚。我在中间执行的交易没有回滚。
我发现的唯一方法是更改服务类，以便我可以将测试设置中创建的 ITransaction 注入其中。但这种方法将事务暴露给 UI 作为副作用，感觉就像只是为了测试而更改我的实现。
有更好的方法来实现这一目标吗？欢迎任何建议或指示。
I'd like to use the rollback pattern for testing my services. These are actually logical services that manage transactions and handle all repository access, called by a Winform UI. The repositories use NHibernate for database operations.
Given NHibernate doesn't support nested transactions, it doesn't work to begin a transaction in test setup and rollback in tear down. My transactions executed in-between were not rolled back.
The only way I've found is changing the service class so that I can inject to it the ITransaction created in test setup. But this method exposes the transaction to the UI as a side-effect and feels like changing my implementation just for testing.
Is there a better way to achieve this? Any suggestions or directions are welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我在之前的一份工作中遇到了同样的问题，老实说，情况非常棘手，我们最终通过测试数据库来回避这个问题。
基本思想是，您有一些数据库的基线快照或基本设置脚本，您可以每天、每小时或每当测试运行时在测试服务器上运行它们 - 无论什么时候合适。我们处理它的方法是通过调用脚本让 SetUp 方法重置到基线；然后，我们将进行所有测试，并在 TearDown 过程中第二次重置到基线（如果需要）。
您甚至可以将基线位置设置为参数，以便可以从 QA 中提取基线以进行不会破坏任何内容的更改，如果您正在测试更改，则可以提取本地基线。总而言之，习惯起来有点别扭，但效果很好，并没有拖累我们的开发进程。
I ran into this same problem at one of my previous jobs, and honestly the situation was so thorny we ended up ducking the problem by having a test database.
The basic idea is that you have some base-line snapshots or base setup script for your database, which you run on your test server daily, hourly, or whenever the tests run - whatever's appropriate. The way we handled it was to have the SetUp method to reset to baselines by invoking a script; we would then do all our tests, and reset to baselines a second time during the TearDown procedure (if we needed).
You can even set up the baseline location as a parameter so you can pull in baselines from QA for changes that shouldn't break anything, and local baselines if you're testing changes. All in all, it was a little awkward to get used to, but it worked well and did not bog down our development process.