Aquí podría ser tu PUBLICIDAD


diseño de interfaz con Linq2Nibernate y IQueryable

votos
2

Cuando se utiliza Linq2Nibernate, ¿es mejor hacer que el Repositorio devuelva un IQueryable?

Tengo entendido que si usa Linq para Nibernate, la consulta no se activará hasta que llame a .First () o Single () ect ect. Entonces, ¿no sería mejor devolver IQueryable de todas las interfaces para que pueda generar \ manipule el árbol de expresiones antes de que se active?

Mis repositorios son llamados por un servicio y heredan de IServicie.

EDITAR:

Primero realmente aprecio todas las respuestas. Pero quiero agregar un poco a la pregunta. Estoy a favor de este diseño. No entiendo completamente las reservas sobre las pruebas. Mientras el proceso sea probado en cada punto, cada punto de filtro, entonces realmente no veo mucha diferencia.

adición:

¿Tiene algún sentido usar Linq2Nibernate si su repositorio no devuelve IQuerrable?

Publicado el 12/03/2009 a las 21:03
fuente por usuario Ted Smith
En otros idiomas...        العربية       

3 respuestas

votos
3

Personalmente, creo que no. El problema al exponer las consultas compostables de su repositorio es que ya no puede probarlas por completo; su comportamiento (y éxito) ahora está a merced de la persona que llama. Por ejemplo, podrían hacer .Where(x=>SomeUnmappedMethod(x))(sin traducción). Agregué más sobre esto aquí .

Si tiene métodos fijos que devuelven (por ejemplo) IList<T>o T[], puede estar seguro de que si funciona en la prueba unitaria, debería funcionar de manera real (salvo errores de configuración). También significa que puede perfilar el DAL de forma aislada y tener una confianza razonable sobre qué SQL (etc.) va a ejecutarse. No puede perfilar / optimizar un DAL que cambia según la persona que llama.

(basado en mi uso LINQ-to-SQL, no LINQ-to-NHibernate específicamente)

Respondida el 12/03/2009 a las 09:05
fuente por usuario Marc Gravell


Aquí podría ser tu PUBLICIDAD


votos
1

Depende de lo que consuma tu "Repositorio" (citas debido a la ambigüedad). Diría que si algo como tu última capa (UI) consume tus clases de repositorio para NO devolver un IQueryable. Sin embargo, si tiene otra capa entre su capa de interfaz de usuario y su capa de acceso a datos, diría que sí, devuelva IQueryable y haga que su capa intermedia maneje la ejecución de la consulta.

EDITAR

En cuanto a la prueba de su Data Layer Layer (DAL) / Repository, diría que, en su mayor parte, a menos que tenga una lógica real (si las declaraciones, etc.) debería haber poca o ninguna prueba. En ese punto, estás probando el marco. Mi sugerencia sería poner otra capa entre su capa de acceso (UI) y el DAL como un BLL o algo que maneje la ejecución de las consultas de IQueryable. De esta manera, su repositorio puede devolver consultas y su BLL puede manejar la ejecución y tal vez hacer alguna lógica que luego puede ser probada.

Respondida el 12/03/2009 a las 09:10
fuente por usuario Chad Moran

votos
0

No voy con IQueryable, pero me gustaría explicar por qué lo hago de forma un poco diferente:

  • Es más fácil burlarse del repositorio, probar el otro código que lo usa
  • Pruebas de integración: la mayoría de las cosas que provocan que se active una consulta se encuentran en el repositorio, por lo que puedo hacer algunas pruebas de integración realmente enfocadas en su contra.
  • Relacionado con el primero, es más fácil verificar que el código esté haciendo llamadas apropiadas al repositorio. Esto se debe a que el código de llamada pasará la información de los filtros a la llamada al método del repositorio, en lugar de aplicarlos contra los resultados.
Respondida el 12/03/2009 a las 09:20
fuente por usuario eglasius