.net - NHibernate con o sin Repositorio
repository-pattern linq-to-nhibernate (3)
Buenas preguntas. También estaba pensando en ellos hace unos días.
En realidad, pruebe NHibernate 3.0 alpha (o el troncal actual), su nuevo proveedor de LINQ es mucho mayor que los anteriores. (Hasta ahora, solo encontré un método que no funciona, pero es posible enganchar tu propio mecanismo si te encuentras con algo que no es compatible por defecto). No tuve problemas (¿todavía?) Con el uso de la troncal actual . Puede encontrar una compilación "nocturna" en el sitio http://www.hornget.net/packages/ , junto con una compilación FluentNHibernate en su contra. Fluido realmente aumenta tu productividad si sabes cómo usarlo. La comunidad SO realmente me ayudó con eso también.
Si está de acuerdo con que su capa de negocios tenga una dependencia directa con NHibernate, o está escribiendo una aplicación más pequeña que se puede mantener sin este tipo de abstracción, está listo sin el patrón de repositorio. Sin embargo, si lo haces bien, puede ahorrarte mucha codificación redundante.
La razón para abstraerlo no solo es útil porque luego puede reemplazar NHibernate con otro ORM, pero es una buena práctica debido a un concepto llamado Separación de preocupaciones . Su capa de lógica de negocios no debería importarle ni saber nada sobre cómo acceder a los datos con los que trabaja. Esto facilita el mantenimiento de la aplicación o sus diferentes capas, lo que también facilita el trabajo en equipo: si X crea la capa de acceso a datos e Y escribe la lógica de negocios, no tienen que conocer el trabajo de los demás en detalle.
Exponer un IQueryable<T> es una muy buena idea, y eso es exactamente lo que están haciendo muchas implementaciones de repositorio en este momento. (Y yo también, aunque preferí escribirlo en una clase estática). Y, por supuesto, tendrá que exponer algunos métodos para insertar o actualizar una entidad, o métodos para comenzar y comprometer transacciones, si así lo desea. (BeginTransaction solo debe devolver un IDisposable para evitar la filtración de una interfaz NHibernate, y eso estará bien).
Puedo darle algunas instrucciones: consulte las implementaciones de SharpArchitecture o FubuMVC Contrib para obtener algunas ideas sobre cómo hacerlo bien, y así es como lo resolví .
Hay varias preguntas similares sobre este tema, porque aún no he encontrado suficientes razones para decidir qué camino tomar.
La pregunta real es, ¿es razonable abstraer el NHibernate usando un patrón de Repository , o not ?
Parece que la única razón detrás de abstraerlo es dejar una opción para reemplazar NHibernate con un ORM diferente si es necesario. Pero crear repositorios y abstraer consultas parece agregar otra capa y hacer la mayor parte de la plomería a mano.
Una opción es usar expose IQueryable<T> a la capa de negocios y usar LINQ, pero desde mi experiencia, el soporte de LINQ todavía no está completamente implementado en NHibernate (las consultas simplemente no funcionan como se esperaba, y odio dedicar tiempo a depurar un marco de referencia).
Aunque hacer referencia a NHibernate en mi capa empresarial me duele la vista, se supone que es una abstracción del acceso a los datos por sí mismo, ¿verdad?
¿Qué opinas sobre esto?
Personalmente prefiero seguir abstrayendo el NHibernate en un patrón de repositorio. El motivo es que podría tener otras implementaciones del repositorio para almacenamiento en caché, simulacros de pruebas de unidades, etc. Y también uso IQueryable con mi repositorio, aunque hago que IRepository extienda IQueryable en lugar de exponer una propiedad en IRepository de tipo IQueryable.
Otro punto de repositorio. Algunas personas sugieren no convertirlo en genérico y tener la identificación de tipo en el nivel del método (es decir, repositorio.Carga). Sin embargo, esto supone que habrá un único repositorio que sabe cómo tratar con todos los tipos. No soy un gran fan de esta noción de un solo repositorio monolítico. ¿Qué pasa si estás tratando con múltiples bases de datos? ¿O múltiples mecanismos de persistencia? O algunos tipos de datos se mantienen bastante estáticos y se pueden almacenar en caché, pero otros no. Es por esto que me gusta una instancia de repositorio separada para cada tipo.
Simplemente diría un gran SÍ! tener un patrón de repositorio, mantener las cosas abstractas!