La verdad es que yo me he planteado ese patrón y he desarrollado usándolo con buenos resultados pero no me acaba de convencer por todos los temas comentados. Mi solución para filtrar los request fue hacer que sólo pudieran iniciar una sesión aquellos archivos con extensión aspx, asmx, ashx... por configuración lógicamente.
Si te basas en un modelo-vista-presentador, también tienes la posibilidad de envolver los métodos del presentador en una transacción/ sesión mediante interceptors, tal y como hace spring o usando CastleWindsor. De esta forma te olvidas de todos los temas de request y te aseguras el ámbito de tu transacción/sessión. Debido a que todos los interceptors se pueden especificar por configuración, reutilizar el modelo en un contexto no web significaría tener un archivo de configuración distinto, simplemente, o ni eso. Te serviría porque, como el presentador actúa con la vista y con el modelo, el ámbito de la sesión puede equivaler a la ejecución de un método del presentador y no finalizaría la sesión hasta que finalice todo el procesamiento, por tanto, incluso puedes hacer uso de lazy- loading donde quieras sin utilizar DTOs. Sería: Iniciar_sesión_transacción(); -> por un interceptor Ejecutar_Metodo_Presentador(); Finalizar_sesión_transacción(); -> por el mismo interceptor También te olvidas de si es ajax o no. ¿Qué os parece esta idea? On 1 abr, 05:07, Nelo Pauselli <[email protected]> wrote: > Si, podés mirar el código de unhaddins por ejemplo... y también hay > otros dando vuelta para preguntar cuando el request necesita de una > session. De todas formas, para las imagenes, js, etc te recomendaría > que configures algún tipo de cache. (si manejas por ejemplo treeviews > con imagenes en los nodos, es casi indispensable configurar la cache y > no ir al servidor por cada imagen). > > Por la combinación AJAX + entidades del dominio en la UI, el problema > que podés tener es si consultas una propiedad que aun no fue cargada > (lazy-loading) en un request diferente al que cargó el objeto. Si > tenés un escenario así te diría que vayas viendo la posibilidad de > implementar DTOs en la UI con un servicio de aplicación que te los > provea. Y quizás, pensando en vos alta, podrías manejar un session per > call a nivel de este SERVICIO DE APLICACIÓN, ya que de este hacia la > UI solo hay DTOs y de esta manera hasta te evitas el abrir sessions en > cada request, porque lo harías solo cuando llamas a un método del > servicio de aplicación. (hace unos días hice un post sobre este > tema:http://nelopauselli.blogspot.com/2010/03/data-transfer-object-dtos.html). > > Siempre hablando de aplicaciones web, claro. > > Saludos. > Nelo. > > 2010/3/31 Jonathan Leibiusky <[email protected]>: > > > > > No no... me entendiste mal. > > Digo de usar el patrón session-per-request pero sin abrirla cuando inicia el > > request sino cuando la usa por primera vez en ese request... como una > > especie de LazySession... de esa forma no hay que complicarse para detectar > > qué tipo de request es. > > Cuando es una imágen, css o cualquier recurso que no usa la DB no la abre y > > listo. > > > 2010/3/31 José F. Romaniello <[email protected]> > > >> El 31 de marzo de 2010 20:09, Jonathan > >> Leibiusky <[email protected]> escribió: > > >>> No sería más sencillo hacer que solamente abra una session la primera vez > >>> que la usa? > >>> No parece muy complicado de implementar. > > >> La primer vez que que?? > >> Session per application es un timebomb en aplicaciones de escritorio, pero > >> session per application en una aplicación web es directamente imposible. > >> Al voleo se me vienen tres cosas que impiden esto: > >> 1-Significa que tu unit of work tiene el ciclo de vida de toda la > >> aplicación? Esto no me gusta del vamos. > >> 2-Session no es thread safe. > >> 3-Por otro lado, luego que una sesión arroja alguna excepción, la sesión > >> queda en un estado fallido que no puede ser usado nuevamente. > >> Para web lo mejor es session per request. > >> Lo que dijo Nelo de mantener la sesión en un pool me parece mala idea > >> también, pero tendría que ver la implementación. > > >> -- > >> 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 -- Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano To unsubscribe, reply using "remove me" as the subject.
