Creo que estoy estancado en la parálisis del análisis. ¡Por favor ayuda!Uso del patrón de diseño de la Unidad de trabajo/Sesiones NHibernate en un MVVM WPF
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?
El primer enlace está muerto – afaolek