Uso del patrón de diseño de la Unidad de trabajo/Sesiones NHibernate en un MVVM WPF

Question

Creo que estoy estancado en la parálisis del análisis. ¡Por favor ayuda!

Actualmente tengo un proyecto que

• Usos NHibernate en SQLite
• implementa el repositorio y la Unidad de patrón de trabajo: estrategia de MVVM http://www.nhforge.org/wikis/patternsandpractices/nhibernate-and-the-unit-of-work-pattern.aspx
• en una aplicación WPF

unidad de trabajo la implementación en mi caso es compatible con una sesión de NHibernate a la vez. Pensé en ese momento que esto tiene sentido; oculta el funcionamiento interno de la sesión NHibernate de ViewModel.

Ahora, según Oren Eini (Ayende): http://msdn.microsoft.com/en-us/magazine/ee819139.aspx

convence a la audiencia que las sesiones de NHibernate se deben crear/eliminados cuando se dispone la vista asociada con el presentador/modelo de vista. Presenta problemas por los que no desea una sesión por aplicación de Windows, ni desea que se cree/deseche una sesión por transacción. Desafortunadamente, esto plantea un problema porque mi interfaz de usuario puede tener más de 10 viewmodels/view presente en una aplicación. Él presenta una estrategia MVP, pero ¿sus consejos se traducen en MVVM?

¿Esto significa que debería eliminar la unidad de trabajo y tener viewmodel crear sesiones de NHibernate directamente? ¿Debería una aplicación WPF solo tener una sesión de trabajo a la vez? Si eso es cierto, ¿cuándo debería crear/eliminar una sesión de NHibernate?

¡Y todavía no he considerado cómo caben las sesiones de NHibernate Stateless en todo esto! Mi cerebro va a explotar. ¡Por favor ayuda!

Actualización:

he encontrado Unidad de Ayende de ejecución de los trabajos en Rhino Herramientas. Descubrí que hay diferencias significativas entre su implementación y la que hice. Definitivamente admitió varias sesiones. Después de más investigación creo que lo mejor es que hago lo siguiente:

• Scrap mi implementación de la Unidad de Trabajo
• renunciar al uso de ISession de NHibernate y IStatelessSession objetos directamente del modelo de vista. Si bien, en mi opinión, no es ideal, ya he dedicado demasiado tiempo a la Unidad de trabajo y no se está adaptando a lo que es. Tengo que aplicar KISS y YAGNI en algún momento. Al menos puedo consolarme con el hecho de que el artículo de Ayende y algunos otros señalan que usarlos directamente está bien.
• Si realmente no quiero exponer ISession, siempre puedo usar Castle.ActiveRecord, pero creo que no es necesario.
• Puedo volver a utilizar el código de Session Factory, por lo que la implementación de la Unidad de trabajo no es un desperdicio total.
• Refactoricé mis repositorios para permitir la inyección de ambos, StatelessSession y Session, y uso el método stateless si está disponible; de ​​lo contrario, use la sesión regular.

Después de todo eso, entonces puede aplicar la estrategia de apertura de una sesión/sesión sin estado por viewmodel y cuando la vista está dispuesto, tener ras viewmodel/disponer la sesión/sesión sin estado.

Suena a plan?

Answer 1

¿Cuál es su verdadera preocupación con la activación de más de 10 sesiones? Las sesiones son objetos livianos que se pueden usar para operaciones pesadas. Si la sesión no está haciendo nada actualmente, es algo insignificante.

Answer 2

Usar UnitOfWork es una limitación importante en una aplicación de cliente, ya que todos los descansos de carga diferida. Pierdes parte de lo que NHibernate es bueno. También se está configurando para las excepciones de tiempo de ejecución, porque no hay nada en el modelo NHibernate que le recuerde que no debe usar estas funciones. Diría que el consejo de Ayendes es bueno.

Answer 3

Personalmente intento mantener las sesiones abiertas durante el menor tiempo posible. La razón principal es que utilizamos el bloqueo pesimista en nuestra raíz agregada principal (estamos usando el diseño impulsado por el dominio), por lo que queremos liberar el bloqueo lo más rápido posible. No olvide que, dado que está utilizando el lado del cliente de NHibernate, puede cerrar su sesión y cuando abra una nueva puede volver a conectar sus entidades desconectadas.

Personalmente, incluso en una aplicación que tenía muchas ventanas/pestañas abiertas a la vez, todavía usaba solo una sesión a la vez. Abriría uno nuevo cuando necesite recuperar datos para una vista o cuando los cambios deban persistir.

En un punto de nuestra aplicación actual, implementamos el soporte de múltiples sesiones en nuestra Unidad de trabajo pero terminamos quitándolo cuando nos dimos cuenta de que no teníamos ningún uso y simplemente complicaba las cosas.

Answer 4

Conozco estas fechas desde hace un tiempo, pero he estado buscando en línea una respuesta decente durante 3 días. Leí los dos blogs que menciona que echaron un vistazo al libro de cocina Nhibernate 3.0 donde también hablan sobre Nhibernate en una aplicación MVP, pero esto no encajaba exactamente en mi contexto MVVM con repositorios y el uso de Ninject para IoC.

he encontrado este antiguo puesto que, como hasta ahora ha sido la página más útil: http://www.emidee.net/index.php/2010/08/23/ninject-use-one-database-session-per-view-model

espero que esto ayude a que tropezar con esta cuestión en el futuro.