Patrón de NHibernate y Repositorio

Question

Patrón de NHibernate y Repositorio

¿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 un ISession en su constructor. ¿Qué me deberían importar las sesiones de NH en mi BL (business layer)?

Crear un montón de repositorios, cada uno de ellos montón de métodos específicos?
Aparentemente, eso es demasiado trabajo porque BL ahora está "permitido" estar al tanto de NHibernate (Repositorio es el nuevo Singleton)?
Crear un único repositorio genérico, pero exponer IQueriable<T> y usar LINQ en BL
De vez en cuando hay una consulta que LINQ-to-NHibernate no será capaz de procesar (o necesito ajustar el SQL manualmente una vez en un centenar de consultas). Esto es fácil con los métodos de repo personalizados, pero casi imposible con código basado en LINQ. Y usar ambos solo porque LINQ está roto en algunos casos es una tontería.
Objetos de Consulta?
QueryOver también es específico de NH, lo que significa que BL es nuevamente consciente de la implementación de DAL.
¿Otro Enfoque?

Obviamente, necesito ser capaz de administrar transacciones en algún lugar , tal vez usando un patten de Unidad de trabajo (aunque también hay muchas implementaciones diferentes de eso alrededor).

22

.net linq repository nhibernate

Author: doe, 2011-07-22

Source

2 answers

El sitio parece estar caído ahora, pero realmente me gusta el enfoque de Bob Craven y lo he utilizado en algunos grandes proyectos:

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

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

Sí, es un ligero dolor cuando necesita recurrir a SQL, pero uso una capa de servicio de datos que puede abstraer eso. Es decir, Servicio de datos layer usa los dao genéricos cuando es posible (el 90% del tiempo) y usa SQL de vainilla/otros frameworks en otros lugares.

2

Author: Mark D,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-07-22 13:18:49

score 13 · Accepted Answer

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

1) Sí, definir un repositorio para cada raíz agregada puede ser exagerado, pero puede encontrar que la forma de recuperar datos para esa raíz puede ser específica para ella y desea poder controlarla en un repositorio personalizado. El artículo de Ayende es muy revelador y golpea de cerca el deseo típico del desarrollador de' over-architect ' soluciones-a menudo en detrimento de funcionalidad.

2) Usar LINQ con NHibernate es una opción, pero destacaría que debe darse la capacidad de recurrir al uso de consultas de criterios o HQL si hace esto. En esa etapa es posible que te encuentres poniendo tantas excepciones que te preguntarás cuál era el punto inicial de la abstracción.

3) QueryOver es un envoltorio seguro de tipo alrededor de las consultas de criterios y esto por sí solo las hace mucho más atractivas para mí. A menudo me encuentro cayendo de nuevo a los criterios para el puro control que ofrecen - la alternativa a menudo es que tengo que usar "cuerdas mágicas". Esto esencialmente harí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 debe ser capaz de manejar especificaciones de consulta (exactamente cómo funciona QueryOver).

En cuanto a las transacciones, depende de su marco. En realidad no creo que sea realista o beneficioso utilizar el unidad de patrón de trabajo en una aplicación y ocultar la implementación de ella (se podría abstraer - pero ¿cuál es el punto? - ¿de verdad vas a cambiar tu OR?)

Si está usando ASP.NET a continuación, solo (como mínimo) iniciar la transacción al inicio de la solicitud, revertir las excepciones y confirmar al final.

Si está utilizando WinForms, es posible que deba considerar la duración de cada tarea de la interfaz de usuario como su unidad de trabajo.