Bueno, eso es lo que haría yo... pero este framework que desarrollo se utiliza en 5 proyectos y de esta forma evito problemas de sesiones. Además, le agregué soporte para trabajar con diferentes orígenes de datos a la vez, osea, que a veces hace falta tener más de una sesión/ transacción abierta (una por origen de datos o sessionfactory).
En un web service ASMX se puede utilizar un session-per-request o qué debería usarse? En WCF uso una implementación de ICallContextInitializer implementando el AfterInvoke y BeforeInvoke. En Web uso session-per-request En MVC uso ActionFilters o IoC en el controlador --> Te parece una mala práctica el uso de interceptors en un controlador? En aplicaciones de consola uso IoC En aplicaciones de formulario uso sesion-por-formulario. Gracias On 18 feb, 14:27, Carlos Peix <[email protected]> wrote: > Hola Juan, > > Las transacciones deberian iniciarse en el punto de acceso a tu logica de > negocio, puede ser sobre una accion de MVC, en un modulo per request en una > pagina o en un webservice, etc. > > Es alli donde debes iniciar transaccion y no en el un metodo de tu capa de > negocio, a menos que esa capa sea lo que se llama fachada de servicios. Si > este fuera el caso, no deberias llamar a otro metodo de la capa de servicios > desde dentro de tu capa de servicios. > > Entonces, nunca tendrias sessiones/transacciones anidadas. > > Se entiende? > > ---------------------------------- > Carlos Peix > > 2011/2/17 Juan Cuello <[email protected]> > > > > > > > > > Hola a todos, > > > Introducción: > > > Mi pregunta va a nivel de concepto de gestión de sesiones en NH. > > Dentro de un framework que se ha desarrollado, el cual usa NH como > > ORM, se realiza la gestión de sesiones mediante interceptors (es una > > de las formas, hay session-per-request, per action en mvc, > > interceptors en el controlador de mvc, etc). Basta con "enchufarle" un > > interceptor al método y automáticamente, si se provoca una excepción > > se hace rollback (en el interceptor) o commit si todo OK. > > > La sesión-transacción que se inicia se guarda en el contexto de > > aplicación (un diccionario de sesiones-transacciones en HttpContext > > para web, OperationContext para WCF y CallContent para lo demás). De > > esta forma evitas que el programador tenga que hacer gestiones de > > sesiones de ninguna forma. Si la aplicación trabaja con varios > > orígenes de datos a la vez, cada método cogerá la sesión que tenga > > disponible para su origen de datos (si la tiene, o la abre). > > > Tema que ocupa: > > > Se ha desarrollado la gestión de sesiones de tal forma que, si un > > método que abre una sesión llama a otro método que también tiene el > > interceptor para la gestión de sesiones, este segundo método reutiliza > > la sesión-transacción existente, no abre una nueva. > > > Si el segundo método hace commit-rollback, en realidad no hace nada > > porque no es el que inició la sesión (si la inició sí que hace commit- > > rollback). > > > La idea era que un método de negocio pueda funcionar por sí mismo y a > > la vez pueda ser llamado por otro método de negocio sin problemas de > > sesión evitando abrir dos sesiones para el mismo origen de datos. Los > > daos/repositorios recogen la sesión del contexto. Creo que se cumple > > el concepto de UnitOfWork de esta forma. > > > Pregunta: > > > ¿Alguien ve algún problema en realizar la gestión de sesiones de esta > > forma? > > > Me preocupa no hacerlo de forma correcta... > > > Muchas gracias > > > -- > > Para escribir al Grupo, hágalo a esta dirección: > > [email protected] > > Para más, visite:http://groups.google.com/group/NHibernate-Hispano -- Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano
