是一个静态库使用NHibernate的正确的方式？ [英] Is a static repository a right way to use NHibernate?

问题描述

我花了晚上阅读StackOverflow的问题，剩下的，也有一些博客条目以及有关的主题链接。所有这些横空出世是非常有益的，但​​我还是觉得他们真的不回答我的问题。

I spent the rest of the evening reading StackOverflow questions and also some blog entries and links about the subject. All of them turned out to be very helpful, but I still feel that they don't really answer my question.

所以，我开发一个简单的Web应用程序。我想创建一个我可以在其他的解决方案之后重用一个可重用的数据访问层。这些99％将Web应用程序。这似乎是一个很好的借口，我学习NHibernate和一些图案的周围。

So, I'm developing a simple web application. I'd like to create a reusable data access layer which I can later reuse in other solutions. 99% of these will be web applications. This seems to be a good excuse for me to learn NHibernate and some of the patterns around it.

我的目标如下：

• 我不想业务逻辑层了解数据库的内部运作任何东西，也没有NHibernate的本身。


• 我要的商业逻辑层对数据访问层的假设尽可能少的数量。


• 我想数据访问层作为简单和容易使用的越好。这将是一个简单的项目，所以我不想过于复杂事情。


• 我想要的数据访问层是作为非侵入性越好。

这是否会考虑到所有这些，我决定使用流行的存储库的模式。我读了有关本网站和各种开发博客这个问题上，我听到工作格局的单位一些东西。

Will all this in mind, I decided to use the popular repository pattern. I read about this subject on this site and on various dev blogs, and I heard some stuff about the unit of work pattern.

我也看了看周围，并检查了各种实现。 （包括FubuMVC contrib和SharpArchitecture，之类的东西在一些博客）我发现大部分的操作与原理相同：他们创造了该实例的工作单位当仓库被实例化，他们开始交易，做的东西，然后提交，然后重新开始。所以，只有一个的Isession 每库，就是这样。然后客户端code需要实例化一个仓库，做的东西吧，然后处理。

I also looked around and checked out various implementations. (Including FubuMVC contrib, and SharpArchitecture, and stuff on some blogs.) I found out that most of these operate with the same principle: They create a "unit of work" which is instantiated when a repository is instantiated, they start a transaction, do stuff, and commit, and then start all over again. So, only one ISession per Repository and that's it. Then the client code needs to instantiate a repository, do stuff with it, and then dispose.

本使用模式不符合我的需要被尽可能的简单化，所以我开始思考别的东西。

This usage pattern doesn't meet my need of being as simplistic as possible, so I began thinking about something else.

我发现NHibernate的已经有一些东西，使工作单位不必要的实现自定义的，那就是 CurrentSessionContext 类。如果我正确地配置会话上下文，并做清理必要的时候，我好去。

I found out that NHibernate already has something which makes custom "unit of work" implementations unnecessary, and that is the CurrentSessionContext class. If I configure the session context correctly, and do the clean up when necessary, I'm good to go.

所以，我想出了这一点：

So, I came up with this:

我有所谓的内部静态类 NHibernateHelper 。首先，它有一个名为 CurrentSessionFactory 静态属性，这在第一次通话，在实例化一个静态字段一个会话工厂，并将其存储。 （一 ISessionFactory 每一的AppDomain 是不够好。）然后，更重要的是，它有一个> CurrentSession静态属性，检查是否有一个的Isession 绑定到当前会话的背景下，如果没有，创建一个，并绑定它，并将其与返回的Isession 绑定到当前会话的上下文。

I have an internal static class called NHibernateHelper. Firstly, it has a static property called CurrentSessionFactory, which upon first call, instantiates a session factory and stores it in a static field. (One ISessionFactory per one AppDomain is good enough.) Then, more importantly, it has a CurrentSession static property, which checks if there is an ISession bound to the current session context, and if not, creates one, and binds it, and it returns with the ISession bound to the current session context.

由于它将被 WebSessionContext 主要用于（因此，有一个的Isession 每的Htt prequest ，虽然单元测试，我配置 ThreadStaticSessionContext ），它应该无缝地协同工作。以及创建和绑定的之后的Isession ，它挂钩的事件处理程序的 HttpContext.Current.ApplicationInstance.EndRequest 事件，该负责清理中的Isession 请求结束后，。 （当然，这不仅会若真的在网络环境中运行。）

Because it will be used mostly with WebSessionContext (so, one ISession per HttpRequest, although for the unit tests, I configured ThreadStaticSessionContext), it should work seamlessly. And after creating and binding an ISession, it hooks an event handler to the HttpContext.Current.ApplicationInstance.EndRequest event, which takes care of cleaning up the ISession after the request ends. (Of course, it only does this if it is really running in a web environment.)

所以，这一切成立， NHibernateHelper 始终能返回一个有效的的Isession ，所以没有必要实例化一个库实例为工作单元，以正常工作。相反，库是与的Isession 从 NHibernateHelper.CurrentSession运行的静态类属性，通过通用的方法，通过公开功能。

So, with all this set up, the NHibernateHelper will always be able to return a valid ISession, so there is no need to instantiate a Repository instance for the "unit of work" to operate properly. Instead, the Repository is a static class which operates with the ISession from the NHibernateHelper.CurrentSession property, and exposes functionality through that by generic methods.

所以，基本上，我结束了两个非常懒惰的单身。

So, basically, I ended up with two very lazy singletons.

我很好奇，你觉得这个怎么样？
它是思维的有效方法，还是我完全偏离轨道在这里？

I'm curious, what do you think about this? Is it a valid way of thinking, or am I completely off track here?

编辑：结果
我必须指出的是，NHibernateHelper类是内部的，所以pretty到消费者的存储库很多看不到的。

I must point out that the NHibernateHelper class is internal, so pretty much invisible to the consumers of the repository.

另一个想法是，为了intoduce依赖注入的解决方案，就是让一个名为接口 IDataProvider ，并在第一次调用的实例化的一个实例库类。 （然而，执行code应该能够照顾上下文的概念也。）

Another idea is, in order to intoduce dependency injection into the solution, is to make an interface named IDataProvider, and instantiate one instance of that upon the first call to the Repository class. (However, the implementing code should be able to take care the concept of context also.)

编辑2：结果
似乎很多人喜欢我的想法，但仍有关于它的答案太少的意见。结果
我可以假设，这是使用NHibernate的，那么正确的方式？ ：P

EDIT 2:
It seems that many people like my idea, but there are still too few opinions about it in the answers.
Can I assume that this is a right way to use NHibernate, then? :P

推荐答案

对于什么是值得的，夏普建筑是做或多或少与你的建议是什么。它结束了每HTTP请求提供一个会话（更准确地说，每个数据库每个HTTP请求一个会话）。你的方法肯定是有效的，还提供了每个请求一个会话。我宁愿preFER在使用静态库和辅助类通过DI SharpArch的清洁OO的方法。

For what it is worth, Sharp Architecture is doing more or less exactly what you are suggesting. It ends up delivering one session per HTTP request (more accurately, one session per database per HTTP request). Your approach is certainly valid and also delivers one session per request. I rather prefer SharpArch's cleaner OO approach via DI over using static repositories and the helper class.

这篇关于是一个静态库使用NHibernate的正确的方式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！