我花了剩下的时间阅读StackOverflow问题,还有一些关于这个主题的博客文章和链接.所有这些都证明是非常有帮助的,但我仍然觉得他们并没有真正回答我的问题.
所以,我正在开发一个简单的Web应用程序.我想创建一个可重用的数据访问层,以后我可以在其他解决方案中重用它.其中99%将是Web应用程序.这似乎是我学习NHibernate及其周围模式的一个很好的借口.
我的目标如下:
考虑到这一切,我决定使用流行的存储库模式.我在这个网站和各种开发博客上阅读了这个主题,我听到了一些关于工作单元模式的内容.
我也环顾四周,检查了各种实现.(包括FubuMVC contrib,SharpArchitecture,以及一些博客上的内容.)我发现大多数这些操作都遵循相同的原则:它们创建了一个"工作单元",在实例化存储库时实例化,它们启动一个事务,做东西,提交,然后重新开始.所以,只有一个ISession每次Repository仅此而已.然后客户端代码需要实例化一个存储库,用它做一些东西,然后处理.
这种使用模式不符合我尽可能简单化的需要,所以我开始考虑其他事情.
我发现NHibernate已经有了使自定义"工作单元"实现变得不必要的东西,那就是CurrentSessionContext类.如果我正确配置会话上下文,并在必要时进行清理,我很高兴.
所以,我想出了这个:
我有一个内部静态类叫NHibernateHelper.首先,它有一个名为的静态属性CurrentSessionFactory,在第一次调用时,实例化会话工厂并将其存储在静态字段中.(ISessionFactory每个人一个AppDomain就足够了.)然后,更重要的是,它有一个CurrentSession静态属性,它检查是否ISession绑定到当前会话上下文,如果没有,则创建一个,并绑定它,然后返回ISession绑定到当前的会话上下文.
因为它主要用于WebSessionContext(所以,ISession每个HttpRequest,虽然对于我配置的单元测试ThreadStaticSessionContext),它应该无缝地工作.在创建并绑定an之后ISession,它会将事件处理程序挂钩到HttpContext.Current.ApplicationInstance.EndRequest事件,该事件处理ISession请求结束后的清理.(当然,只有当它真的在Web环境中运行时才会这样做.)
因此,通过所有这些设置,NHibernateHelper将始终能够返回有效的ISession,因此无需为"工作单元"实例化Repository实例以使其正常运行.相反,Repository是与工作的静态类ISession从NHibernateHelper.CurrentSession性能,并通过通用的方法,公开通过该功能.
所以,基本上,我最终得到了两个非常懒惰的单身人士.
我好奇,你怎么看待这个？这是一种有效的思维方式,还是我完全偏离了这里？
编辑:
我必须指出NHibernateHelper类是内部的,因此对于存储库的使用者来说几乎是不可见的.
另一个想法是,为了将依赖注入引入解决方案,就是创建一个名为的接口IDataProvider,并在第一次调用Repository该类时实例化该接口的一个实例.(但是,实现代码也应该能够关注上下文的概念.)
编辑2:
似乎很多人都喜欢我的想法,但在答案中对它的看法仍然太少.
我可以假设这是使用NHibernate的正确方法吗？:P