在 MVVM WPF 中使用工作单元设计模式/NHibernate 会话
我想我陷入了分析的瘫痪之中。请帮忙！
的项目
- 我目前有一个在 SQLite 上使用 NHibernate
- 实现存储库和工作单元模式 ：http://www.nhforge.org/wikis/patternsandpractices/nhibernate-and-the-unit-of-work-pattern.aspx
- WPF 应用程序
单元 中的 MVVM 策略在我的例子中，Work 实现一次支持一个 NHibernate 会话。我当时觉得这是有道理的；它向 ViewModel 隐藏了 NHibernate 会话的内部工作原理。
现在，根据 Oren Eini (Ayende) 的说法：http://msdn.microsoft。 com/en-us/magazine/ee819139.aspx
他让观众相信，当与演示者/视图模型关联的视图被释放时，NHibernate 会话应该被创建/释放。他提出了为什么您不希望每个 Windows 应用程序有一个会话，也不希望每个事务创建/处置一个会话的问题。不幸的是，这带来了一个问题，因为我的 UI 可以轻松地在应用程序中存在 10 多个视图/视图模型。他正在使用 MVP 策略进行演示，但他的建议是否可以转化为 MVVM？
这是否意味着我应该废弃工作单元并让 viewmodel 直接创建 NHibernate 会话？ WPF 应用程序一次只能有一个工作会话吗？如果这是真的，我应该什么时候创建/处置 NHibernate 会话？
我还没有考虑 NHibernate 无状态会话如何适应这一切！我的大脑快要爆炸了。请帮忙！
更新：
我在Rhino Tools中找到了Ayende的工作单元实现。我发现他的实现和我的实现有很大的不同。他绝对支持多次会议。经过进一步研究，我认为最好执行以下操作：
- 废弃工作单元的实现 放弃
- 直接从视图模型使用 NHibernate 的 ISession 和 IStatelessSession 对象。虽然我认为这并不理想，但我已经在工作单元上花费了太多时间，而且它并没有达到应有的效果。在某些时候必须应用 KISS 和 YAGNI。我至少可以得到安慰，因为 Ayende 的文章和其他一些人指出直接使用这些是可以的。
- 如果我真的不想暴露 ISession，我总是可以使用 Castle.ActiveRecord，但我认为这是没有必要的。
- 我可以重用会话工厂代码，因此工作单元实现并不是完全浪费。
- 重构我的存储库以允许注入 StatelessSession 和 Session，并在可用时使用无状态：否则使用常规会话。
毕竟，然后我可以应用为每个视图模型打开一个会话/无状态会话的策略，并且当视图被处置时，让视图模型刷新/处置会话/无状态会话。
听起来像一个计划吗？
I think I am stuck in the paralysis of analysis. Please help!
I currently have a project that
- Uses NHibernate on SQLite
- Implements Repository and Unit of Work pattern: http://www.nhforge.org/wikis/patternsandpractices/nhibernate-and-the-unit-of-work-pattern.aspx
- MVVM strategy in a WPF app
Unit of Work implementation in my case supports one NHibernate session at a time. I thought at the time that this makes sense; it hides inner workings of NHibernate session from ViewModel.
Now, according to Oren Eini (Ayende): http://msdn.microsoft.com/en-us/magazine/ee819139.aspx
He convinces the audience that NHibernate sessions should be created / disposed when the view associated with the presenter / viewmodel is disposed. He presents issues why you don't want one session per windows app, nor do you want a session to be created / disposed per transaction. This unfortunately poses a problem because my UI can easily have 10+ view/viewmodels present in an app. He is presenting using a MVP strategy, but does his advice translate to MVVM?
Does this mean that I should scrap the unit of work and have viewmodel create NHibernate sessions directly? Should a WPF app only have one working session at a time? If that is true, when should I create / dispose a NHibernate session?
And I still haven't considered how NHibernate Stateless sessions fit into all this! My brain is going to explode. Please help!
Update:
I found Ayende's Unit of Work implementation in Rhino Tools. I discovered that there are significant differences between his implementation and the one I did. His definitely supported multiple sessions. After further research I think it is best that I do the following:
- Scrap my implementation of Unit of Work
- Resign to using NHibernate's ISession and IStatelessSession objects directly from viewmodel. While in my opinion it's not ideal, I've already spent too much time on Unit of Work and it's not shaping up to what it is. Gotta apply KISS and YAGNI at some point. I can at least take solace in the fact that Ayende's article and a few others point out that using those directly is OK.
- If I really really don't want to expose ISession, I can always use Castle.ActiveRecord, but I think that's not necessary.
- I can re-use the Session Factory code, so the Unit of Work implementation is not a total waste.
- Refactored my repositories to allow injection of both StatelessSession and Session, and use stateless if it's available: otherwise use regular session.
After all that, then I can apply the strategy of opening one session / stateless session per viewmodel and when view is disposed, have viewmodel flush / dispose the session / stateless session.
Sounds like a plan?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我知道这是不久前的事情，但我已经在网上寻找合适的答案三天了。
我阅读了您提到的两个博客，并查看了 Nhibernate 3.0 食谱，其中他们还讨论了 MVP 应用程序中的 Nhibernate，但这并不完全适合我的 MVVM 环境以及存储库和使用 Ninject 进行 IoC。
我发现这篇旧文章迄今为止是最有用的页面：
http:// /www.emidee.net/index.php/2010/08/23/ninject-use-one-database-session-per-view-model
我希望这可以帮助任何将来偶然发现这个问题的人。
I know this dates from a while ago but I've been looking online for a decent answer for 3 days.
I read the two blogs you mention had a look at the Nhibernate 3.0 cookbook where they also talk about Nhibernate in a MVP application but this didn't fit exactly in my MVVM context with repositories and using Ninject for IoC.
I've found this old post which as so far been the most useful page:
http://www.emidee.net/index.php/2010/08/23/ninject-use-one-database-session-per-view-model
I hope this helps anyone who will stumble upon this question in the future.
对于 10 多个活动会话，您真正关心的是什么？会话是可用于重量级操作的轻量级对象。如果会话当前没有执行任何操作，则意义不大。
What is your actual concern with having 10+ sessions active? Sessions are light-weight objects that can be used for heavy-weight operations. If the session isn't currently doing anything, it's kind of insignificant.
在客户端应用程序中使用 UnitOfWork 会受到严重限制，因为所有延迟加载都会中断。你失去了 NHibernate 所擅长的部分功能。您还可以为自己设置运行时异常，因为 NHibernate 模型中没有任何内容可以提醒您不要使用这些功能。
我想说艾延德斯的建议很好。
Using UnitOfWork is seriously limiting in a client app, as all lazy-loading breaks. You lose part of what NHibernate is good at. You're also setting yourself up for runtime exceptions, because there is nothing in the NHibernate model to remind you not to use these features.
I'd say Ayendes advice is good.
就我个人而言，我会尽量缩短会议的开放时间。主要原因是我们在主聚合根上使用悲观锁定（我们使用域驱动设计），因此我们希望尽快释放锁定。不要忘记，由于您使用的是 NHibernate 客户端，因此您可以关闭会话，并且当您打开新会话时，您可以重新连接断开的实体。
就我个人而言，即使在一个同时打开多个窗口/选项卡的应用程序中，我仍然一次只使用一个会话。当我需要检索视图的数据或需要保留更改时，我会打开一个新的视图。
在我们当前的应用程序中，我们曾经在工作单元中实现了多会话支持，但当我们意识到它没有任何用处并且它只是让事情变得复杂时，最终将其删除。
Personally I try to keep sessions open for as little time as possible. The main reason being that we use pessimistic locking on our main aggregate root (we're using domain driven design) so we want to release the lock as quickly as possible. Don't forget that since you're using NHibernate client side you can close your session and when you open a new one you can reconnect your disconnected entities back.
Personally even in an app which had many windows/tabs open at once I'd still use only one session at a time. I would open a fresh one when I need to retrieve data for a view or when changes need to be persisted.
At one point in our current app we implemented multi session support in our Unit Of Work but ended up taking it out when we realized we didn't have any use for it and it just complicated things.