Hola Edgar,

Es otra forma de implementarlo, utilizando un unit of work (un ámbito) más
amplio que sería una sesión de NHibernate por petición.
Personalmente los dos modos más eficientes para gestionar la sesión de
NHibernate sería Session por petición y Session por acción.
La sesión por petición de usaría del modo en que describes (quizás algo
menos rebuscado también se podría) mediante un httpmodule lo cual no ofrece
una validez de sesión de NHibernate durante toda (y todas!) la petición,
incluyendo el renderizado de la vista.
La sesión por acción por otro lado, se define en un ámbito más acotado,
solamente durante la ejecución de la acción concreta dentro de nuestro
controlador (ya sea un MVCController o un ApiController) y no es efectiva
durante el código de la vista.

Estos diferentes ámbitos de sesión tienen unos pros y contras o
particularidades a tener en cuenta:

Sesión por petición:
1.- Se ejecuta para todas las peticiones (incluyendo llamadas a ficheros
estáticos como imágenes, css, js...)
2.- La sesión está activa durante la renderización del código incrustado en
la vista, lo que permite que se lancen consultas desde la vista (en lo que
a MVC se refiere, en WebAPI esto es irrelevante por que no hay vista).
Permitir que la vista realice consultas por si misma (por ejemplo mediante
el lazy load) no es una práctica recomendada ya que rompe parte de la idea
del patrón de diseño MVC donde la vista no debiera tener acceso al origen
de datos.
3.- La sesión por petición es más flexible ya que su ámbito es mayor y nos
permite tener una gestión única tanto para lazy load(aunque no sea
recomendado) en la vista, para los controladores mvc y para los
controladores web api

El punto 1 se puede "solucionar" poniendo una condición en el BeginRequest
para que sólo se inicialice la sesión si el PhysicalPath de la Request no
existe físicamente como fichero, es decir, es una ruta virtual por lo que
es una acción de un controlador con casi completa seguridad. Añadiendo
también una condición en el EndRequest para sólo ejecutar la lógica de
cierre de sesión si se encuentra vinculado al contexto de la petición.

Sesión por acción:
1.- Se ejecuta únicamente durante el código interno de la acción y nada más
que ahí, permitiendo tener el acceso a la sesión controlado, localizado y
acotado
2.- Evita que caigamos en malas prácticas como cargar datos desde la vista
3.- La sesión no se carga en peticiones a ficheros estáticos donde no es
necesaria como las imágenes, css, js...
4.- Debemos implementar una sesión diferente para los controladores MVC y
para los controladores WebAPI

Como comento las dos opciones son válidas y ambas tienen puntos fuertes y
débiles. Personalmente y sobretodo para WebAPI yo me quedo con sesión por
acción.


El 28 de enero de 2015, 15:34, Edgar Ramos <[email protected]> escribió:

> Gracias Carlos, que opinion se tiene sobre el manejo de la session
> implementado de esta forma
>
>
> http://stackoverflow.com/questions/24987497/web-api-2-http-module-endrequest-event-being-fired-first
>
> El codigo que se expone ahi, me parece que viene de una implementacion que
> la hizo hace algun tiempo José F. Romaniello, yo la he utilizado en una app
> asp net mvc
> pero veo que es posible aplicarla a web api, todavia no lo hecho por
> cierto.
>
>
>
> El 26 de enero de 2015, 13:33, Carlos Casado <[email protected]>
> escribió:
>
> Hola Edgar,
>>
>> Yo personalmente implementé para web api un action filter teniendo así un
>> contexto de NHibernatePerAction pero para WebApi.
>> Adjunto la clase del action filter.
>>
>> El 26 de enero de 2015, 17:50, Edgar Ramos <[email protected]>
>> escribió:
>>
>>> Gente algun buen link de referencia para manejar la session de nh en una
>>> app asp net web api 2
>>>
>>> Muchas gracias
>>>
>>> --
>>> Saludos
>>> Edgar
>>>
>>> --
>>> --
>>> Para escribir al Grupo, hágalo a esta dirección:
>>> [email protected]
>>> Para más, visite: http://groups.google.com/group/NHibernate-Hispano
>>> ---
>>> Has recibido este mensaje porque estás suscrito al grupo
>>> "NHibernate-Hispano" de Grupos de Google.
>>> Para anular la suscripción a este grupo y dejar de recibir sus mensajes,
>>> envía un correo electrónico a
>>> [email protected].
>>> Para acceder a más opciones, visita https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> .-Salu2-.
>>
>> --
>> --
>> Para escribir al Grupo, hágalo a esta dirección:
>> [email protected]
>> Para más, visite: http://groups.google.com/group/NHibernate-Hispano
>> ---
>> Has recibido este mensaje porque estás suscrito al grupo
>> "NHibernate-Hispano" de Grupos de Google.
>> Para anular la suscripción a este grupo y dejar de recibir sus mensajes,
>> envía un correo electrónico a
>> [email protected].
>> Para acceder a más opciones, visita https://groups.google.com/d/optout.
>>
>
>
>
> --
> Saludos
> Edgar
>
> --
> --
> Para escribir al Grupo, hágalo a esta dirección:
> [email protected]
> Para más, visite: http://groups.google.com/group/NHibernate-Hispano
> ---
> Has recibido este mensaje porque estás suscrito al grupo
> "NHibernate-Hispano" de Grupos de Google.
> Para anular la suscripción a este grupo y dejar de recibir sus mensajes,
> envía un correo electrónico a
> [email protected].
> Para acceder a más opciones, visita https://groups.google.com/d/optout.
>



-- 
.-Salu2-.

-- 
-- 
Para escribir al Grupo, hágalo a esta dirección: 
[email protected]
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
--- 
Has recibido este mensaje porque estás suscrito al grupo "NHibernate-Hispano" 
de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía 
un correo electrónico a [email protected].
Para obtener más opciones, visita https://groups.google.com/d/optout.

Responder a