¿Por qué se necesita el patrón de repositorio en NHibernate?

13

Estoy leyendo el oficial Tu primera aplicación basada en NHibernate .

Si bien el tutorial es bueno y fácil de seguir, me pregunto por qué se usa el patrón Repository.

En las diversas Add, Update, Removemétodos en la ProductRepositoryimplementación, el código es casi idéntica - todos ellos están utilizando transacciones, y la diferencia está en la "carne", es decir llamada session.Saveint el Addmétodo, session.Deleteen el removemétodo. ( La página carece de anclajes HTML, pero puede buscar en la página el código relevante como public void Remove,public void Add )

Ese código simplemente "se siente mal".

¿Por qué el autor usa el patrón Repository? ¿Es solo para demostrar el uso de NHibernate o es necesario o por alguna otra razón?

PD. Mi experiencia es de Ruby on Rails usando ActiveRecord, así que estoy tratando de entender cómo funciona / se utiliza NHibernate.

c# .net nhibernate

— Zabba
fuente

1

Si prefiere el patrón ACtive Record, puede usar Castle Active Record para sentarse encima de NHibernate castleproject.org/activerecord

— Ben Robinson el

3

Esta es una pregunta crítica. Se está discutiendo si usarlo o no. Ayende escribió sus argumentos para no usarlo en Repository is the new Singleton

10

No se requiere el patrón de repositorio. En cuanto a todos los demás patrones, es una decisión "arquitectónica" que debe tomar contra las necesidades de su negocio. En general, el Patrón de repositorio se utiliza para implementar la "Ingorancia de persistencia de entidad", lo que significa que sus entidades no saben nada sobre cómo persistir en su dispositivo de almacenamiento (Base de datos, XML, TextFile, etc.). Si, por ejemplo, tiene una dirección de entidad, no contendrá la lógica de persistencia (no encontrará en ninguna parte algo como address.Save o address.Update) pero pasará su entidad a un método de repositorio que se encarga de persistir cambios

— Massimiliano Peluso
fuente

Pienso que si y no. La sesión de NHibernate en sí misma es un repositorio genérico. Por lo tanto, agregar un repositorio adicional no es, en general, más que agregar una fachada al objeto de sesión.

de hecho, mi respuesta comienza como "No se requiere el patrón del repositorio ..." puede ser solo una decisión arquitectónica contra las necesidades del negocio, eso es todo

Estoy totalmente de acuerdo en eso. Pero me estaba perdiendo el punto de que la sesión en sí misma es un repositorio, eso es todo.

9

La ventaja de usar el patrón de repositorio es burlarse de su capa de acceso a datos, para que pueda probar el código de su capa empresarial sin llamar al código DAL. Hay otras grandes ventajas, pero esto parece ser muy vital para mí.

2

+1 el patrón ActiveRecord hace que sea muy difícil aislar el DAL para burlarse, generalmente terminando con las pruebas unitarias que requieren su propia base de datos (en cuyo caso la prueba unitaria se convierte en una prueba de integración).

— MattDavey