问题
I am having issues editing and deleting objects and i think its because i am not sharing the same session objects between my repository classes and my unitofwork class. I am trying to find some document on the best way to wire this up so I share the same session object.
I am using ninject as my IOC container in the mvc website.
回答1:
I usually set the session as a dependency of the repository, so Ninject can resolve the dependency (ISession = NHibernate.ISession):
public UserRepository(ISession session)
{
...
}
This is how I set the binding:
kernel.Bind<ISession>().ToMethod(x => GetRequestSession()).InRequestScope();
So when a session is required Ninject will call GetRequestSession() to retrieve the session. The function is implemented as follows:
private static ISession GetRequestSession()
{
IDictionary httpContextItems = HttpContext.Current.Items;
ISession session;
if (!httpContextItems.Contains(MvcApplication.SESSION_KEY))
{
// Create an NHibernate session for this request
session = MvcApplication.SessionFactory.OpenSession();
httpContextItems.Add(MvcApplication.SESSION_KEY, session);
}
else
{
// Re-use the NHibernate session for this request
session = (ISession)httpContextItems[MvcApplication.SESSION_KEY];
}
return session;
}
The NHibernate session is stored in the HttpContext items. This is a key-value collection which can be used to store and share data during the handlng of one request.
The session is created only once per request, and is re-used during the request.
MvcApplication.SESSION_KEY is just a constant string I defined in Global.asax to be able to store and retrieve the session from the HttpContext. Also the session factory is located in global.asax and is created at start-up.
Your unit of work class could also set the ISession as a dependency, so Ninject will resolve this dependency as well and therefore use the same session. On the other hand, you might not need a unit of work class, because NHibernate's implementation of ISession in itself is already a unit of work class.
I'm not sure if this is a best practice, but it works perfectly for me.
回答2:
Nhibernate has a built in mechanism to share sessions, that is contexts. Based on the application you can use appropriate context. For more details,
http://nhibernate.info/doc/nhibernate-reference/architecture.html#architecture-current-session
回答3:
If Robin's answer isn't working for you, you could have a misconfiguration with Ninject.
I ran into a very similar issue this morning with updates. In my case I was reading objects from a session bound to an object in a different scope than the session I was writing to.
Here's my simple, SessionProvider:
public class SessionProvider : Provider<ISession>
{
protected override ISession CreateInstance(IContext context)
{
var factory = context.Kernel.Get<ISessionFactory>();
var session = factory.OpenSession();
return session;
}
}
and IOC code:
kernel.Bind<ISessionFactory>().ToProvider<SessionFactoryProvider>();
kernel.Bind<ISession>().ToProvider<SessionProvider>().InRequestScope();
The simplest way to ensure both your Unit of Work and your Repository are instantiated with the same ISession is to ensure they are both also created in request scope. That, however, should be the default.
Depending on how you've installed NInject and what version you're using, you may have to install an HTTP module to ensure Request scope works correctly:
- If you installed the NuGet package, it will have added
DynamicModuleUtility.RegisterModule(typeof(OnePerRequestHttpModule));
- If you have an older version of Ninject, you could also add the module to web.config using
<add name="OnePerRequestModule" type="Ninject.Core.Behavior.OnePerRequestModule, Ninject.Core"/>
- If you are using a newer Ninject, it's in
<add name="OnePerRequestHttpModule" type="Ninject.Web.Common.OnePerRequestHttpModule, Ninject.Web.Common"/>
来源:https://stackoverflow.com/questions/12649911/what-is-the-right-way-to-ensure-your-repository-and-unitofwork-class-share-the-s