.net - Patrón de NHibernate y Repositorio

linq repository

Question

¿Cuál es el enfoque recomendado para tomar con el patrón de Repositorio Nhibernate +?

Hay tantos artículos y opiniones diferentes que no estoy seguro de qué camino tomar. Tomemos este largo artículo , por ejemplo. Da un ejemplo de objetos de consulta, pero cada repositorio concreto acepta una ISession en su constructor. ¿Qué debería preocuparme por las sesiones de NH en mi BL (capa empresarial)?

1. ¿Crear un montón de repositorios, cada uno de ellos con un montón de métodos específicos?
   Aparentemente, eso es demasiado trabajo porque ahora se "permite" que BL esté al tanto de NHibernate (¿El repositorio es el nuevo Singleton )?

2. Cree un único repositorio genérico, pero exponga IQueriable<T> y use LINQ en BL
   De vez en cuando hay una consulta que LINQ-to-NHibernate no podrá procesar (o tengo que modificar el SQL manualmente una vez en cien consultas). Esto es fácil con los métodos de recuperación personalizados, pero casi imposible con el código que se basa en LINQ. Y usar ambos solo porque LINQ está roto en algunos casos no tiene sentido.

3. ¿Consulta objetos?
   QueryOver también es específico de NH, lo que significa que BL es consciente de la implementación de DAL.

4. ¿Otro enfoque más?

Obviamente, necesito poder administrar las transacciones en algún lugar , tal vez utilizando un modelo de Unidad de trabajo (aunque también hay muchas implementaciones diferentes de eso).

Answer 1

El sitio parece estar abajo ahora, pero realmente me gusta el enfoque de Bob Craven y lo he usado en algunos proyectos grandes:

http://blog.bobcravens.com/2010/06/the-repository-pattern-with-linq-to-fluent-nhibernate-and-mysql/ EDIT: versión de Google caché del enlace

Utiliza genéricos y un patrón UOW para el acceso a datos.

Sí, es un ligero dolor cuando necesitas recurrir a SQL, pero uso una capa de servicio de datos que puede abstraer eso. Es decir, la capa de servicio de datos usa el dao genérico siempre que sea posible (90% del tiempo) y utiliza marcos de SQL de vainilla / otros en otros lugares.

Answer 2

Hay muchas opiniones conflictivas dentro del mundo de la arquitectura de software y muchas de ellas están muy bien fundadas.

1) Sí, la definición de un repositorio para cada raíz agregada puede ser excesiva, pero es posible que la forma en que recupere los datos de esa raíz sea específica para él y desee poder controlarlo en un repositorio personalizado. El artículo de Ayende es muy revelador y afecta al deseo del desarrollador típico de "sobre-diseñar" las soluciones, a menudo en detrimento de la funcionalidad.

2) Usar LINQ con NHibernate es una opción, pero me gustaría hacer hincapié en que debe darse la posibilidad de recurrir al uso de consultas de criterios o HQL si hace esto. En esa etapa, es posible que se encuentre en tantas excepciones que se preguntará cuál fue el punto inicial de la abstracción.

3) QueryOver es una envoltura segura para el tipo alrededor de las consultas de criterios y esto solo las hace mucho más atractivas para mí. Muy a menudo me encuentro recurriendo a los criterios para el control absoluto que ofrecen, la alternativa es que tengo que usar "cadenas mágicas". Esto esencialmente haría a NHibernate su abstracción de acceso a datos. De hecho, sería una mejor abstracción que la mayoría de los ''repositorios'' porque la mayoría de ellos solo proporcionan métodos CRUD ... un repositorio debería poder manejar las especificaciones de consulta (exactamente cómo funciona QueryOver ).

En lo que respecta a las transacciones, depende de su marco. En realidad, no creo que sea realista o beneficioso usar la unidad de patrón de trabajo en una aplicación y ocultar la implementación de ella (podría abstraerla, pero ¿cuál es el punto? ¿Realmente va a cambiar su ORM?)

Si está utilizando ASP.NET, solo inicie (como mínimo) la transacción al inicio de la solicitud, restituya las excepciones y confirme al final.

Si está utilizando WinForms, es posible que deba considerar la vida útil de cada tarea de UI como su unidad de trabajo.