¿Cómo puedo implementar la sesión NHibernate por solicitud sin una dependencia en NHibernate?

Question

He planteado esta pregunta anteriormente, pero aún estoy luchando por encontrar un ejemplo que pueda entender (no me digan que mire el proyecto de arquitectura S # arp sin al menos algunas indicaciones).

Hasta ahora he logrado ignorancia de persistencia en mi proyecto web. Mis clases de repositorio (en mi proyecto de datos) tienen un ISession en el constructor:

public class ProductRepository : IProductRepository 
{ 
    private ISession _session; 
    public ProductRepository(ISession session) { 
     _session = session; 
    } 

En mi Global.asax que exponga la sesión actual y estoy creando y disponer sesión sobre BeginRequest y EndRequest (aquí es donde tengo el dependencia de NHibernate):

public static ISessionFactory SessionFactory = CreateSessionFactory(); 

    private static ISessionFactory CreateSessionFactory() { 
     return new Configuration() 
      .Configure() 
      .BuildSessionFactory(); 
    } 

    protected MvcApplication() { 
     BeginRequest += delegate { 
      CurrentSessionContext.Bind(SessionFactory.OpenSession()); 
     }; 
     EndRequest += delegate { 
      CurrentSessionContext.Unbind(SessionFactory).Dispose(); 
     }; 
    } 

y finalmente mi registro StructureMap:

public AppRegistry() { 
     For<ISession>().TheDefault 
      .Is.ConstructedBy(x => MvcApplication.SessionFactory.GetCurrentSession()); 

     For<IProductRepository>().Use<ProductRepository>(); 
    } 

parecería que necesito mis propias implementaciones genéricas de ISession y ¿ISessionFactory que puedo usar en mi proyecto web e inyectar en mis repositorios?

Solo para aclarar: estoy usando NHibernate en mi capa de repositorio y quiero usar una solicitud de sesión por (http). Por lo tanto, estoy inyectando una ISession en mis constructores de repositorio (usando structuremap). Actualmente, para crear y eliminar las sesiones en cada solicitud, he tenido que hacer referencia a NHibernate desde mi proyecto web. Esta es la dependencia que me gustaría eliminar.

Gracias, Ben

Answer 1

¿Por qué no crear un IHttpModule y llevar a cabo su creación y disponer allí (probablemente en el Begin_Request y eventos End_Request), pero pone su IHttpModule dentro del proyecto que tiene su dependencia NHibernate . p.ej.

namespace MyWebApp.Repository.NHibernateImpl 
{ 
    public class NHibernateModule : IHttpModule 
    { 
     public void Init(HttpApplication context) 
     { 
      context.BeginRequest += new EventHandler(Context_BeginRequest); 
      context.EndRequest += new EventHandler(Context_EndRequest); 
     } 

     private void Context_BeginRequest(object sender, EventArgs e) 
     { 
      // Create your ISession 
     } 

     private void Context_EndRequest(object sender, EventArgs e) 
     { 
      // Close/Dispose your ISession 
     } 

     public void Dispose() 
     { 
      // Perhaps dispose of your ISessionFactory here 
     } 
    } 
} 

Quizás haya una mejor manera, estoy interesado en saber esto también, entonces ¿alguna sugerencia alternativa?

Answer 2

Gracias por la ayuda de todos hasta ahora. Un poco más de investigación me llevó al proyecto NHibernate Burrow.

Desde el FAQ proyecto (http://nhforge.org/wikis/burrow/faq.aspx):

madriguera es un middleware de peso ligero desarrollado para soportar aplicaciones .Net utilizando NHibernate (tal vez también conocida como NH en este artículo) como marco ORM. Usar Asp.net con NHibernate podría ser un desafío debido al hecho de que NHibernate es un entorno con estado, mientras que Asp.net es un marco sin estado. Burrow puede ayudar a resolver este conflicto al proporcionar una gestión de sesión/transacción inteligente y avanzada y otras facilidades.

Tuve que saltar unos aros para que funcione en mi proyecto. Dado que el lanzamiento actual usa una versión anterior de NHibernate, tuve que descargar el latest source del trunk, abrir en VS, agregar referencias a la última versión de NHibernate y volver a compilar (afortunadamente no hay errores).

He probado NHibernate Burrow de varias maneras.

1) Continuar inyectando ISession en mis repositorios

Para ello, he tenido que añadir referencias a NHibernate, NHibernate.Burrow y NHibernate.Burrow.WebUtil para mi proyecto MVC.

En web.config que tuvo que establecer Madriguera (ver http://nhforge.org/wikis/burrow/get-started.aspx) y luego en mi registro StructureMap añadir lo siguiente:

 For<ISession>() 
      .TheDefault.Is 
      .ConstructedBy(x => new NHibernate.Burrow.BurrowFramework().GetSession());   

me gusta este enfoque, ya que significa mis repositorios (o controladores) no son junto con Burrow. Realmente no me gusta el hecho de que tengo que hacer referencia a estos tres ensamblajes en mi proyecto web, pero al menos pierdo el código para administrar la sesión; todo esto lo maneja Burrow.

2) El segundo enfoque sería establecer ISession en mis constructores repositorio de este modo:

public ProductRepository() : 
     this(new BurrowFramework().GetSession()) { } 

    public ProductRepository(ISession session) { 
     _session = session; 
    } 

Todavía puedo anular ISession hacer mis repositorios comprobable. Entonces tengo una dependencia directa de Burrow, pero tal vez esto no sea tan malo?

En el lado positivo, el único conjunto al que debo hacer referencia desde mi proyecto web es NHibernate.Burrow.WebUtils.

Interesado en ver cuál de las dos personas iría y por qué.

Answer 3

En mi opinión, debería abrazar la ISession y trabajar con ella directamente. El problema con muchas implementaciones de sesión por solicitud es que retrasan la realización de cambios en la base de datos hasta el final de la solicitud HTTP. Si la transacción falla, todo lo que puede hacer en ese punto es dirigir al usuario a una página de error genérica. Es mucho mejor administrar la transacción en la página para que pueda detectar y manejar los errores de manera más efectiva. Si toma esta ruta, entonces necesita acceder a la ISession o un contenedor para controlar la transacción.

Además, en algún momento su aplicación probablemente necesite usar propiedades o métodos expuestos por ISession, especialmente Merge y Load.