Lo que escribí en el artículo, capturé unas 10 horas, fueron 10 horas de depuración continua que se redujeron a una comparación paso a paso de las versiones del código que funcionan y las que no funcionan, ni siquiera eso, para comparar cada línea desde la ventana de depuración de las versiones del código que funcionan y no funcionan
Para un programador que no está familiarizado con los árboles de expresión, un buen artículo introductorio sobre msdn revela en detalle algunos pasos para construir un árbol que omití en el artículo.
En cuyo caso, esta prueba será verde (el complemento EF está habilitado, en el que se bloquea si no puede traducir completamente la consulta a SQL ).
- Primero, la asignación del campo PupilName debe definirse si no está definida. El proveedor de consultas no reconoce en qué se debe proyectar la propiedad PupilName para agregar a SQL ORDER BY .
En segundo lugar, el proveedor debe analizar este mapeo, por ejemplo, no funcionará, EF comenzará a maldecir (por defecto no lo hace, genera entidades en la memoria - LINQ to Object , pero esto se puede habilitar ):
Y es que el proveedor de consultas no comprende por qué propiedad (s) de la entidad que queremos ordenar. Pero si la asignación se escribe correctamente, el proveedor hará frente, enviará una consulta SQL , recibirá una respuesta y deserializará los resultados.
A veces se hace necesario escribir Expresiones usted mismo, es decir, algo similar:
Le mostraré cómo escribir esta expresión , no es tan difícil, el enlace de arriba proporciona varios ejemplos similares:
Recopilamos el lambda paso a paso, primero un parámetro, una propiedad y luego pegamos todo.
¿En qué caso esto no funcionará y la prueba será verde (el proveedor no podrá analizar la expresión)?
No lo sabes No se preocupe, yo tampoco lo sabía, y al final pasé unas 10 horas para entenderlo.
Aquí hay una pista, esto funcionará:
PupilDto hereda de PupilDtoBase El hecho es que PropertyInfo debe tomarse de la clase base si la propiedad PupilName en sí pertenece a la clase base, por lo que C # construye la expresión lambda y EF los analiza, basándose en estándares de lenguaje
PruebasLo que muestra el depurador si escribe una lambda normal en OrderBy :
Y en nuestro caso, así:
AutoMapper e IncludeBase
Si intenta no duplicar el código, entonces probablemente se topó con la herencia de DTO e IncludeBase :
Hay una situación aún más sofisticada:
Y esta prueba será verde:
Y la cosa es la misma, nuevamente PropertyInfo se extrae de la interfaz:
PruebasLa propiedad ReflectedType of the Age es una interfaz, IPupilDto , C # crea una lambda, en la que la propiedad Age es una propiedad de la clase PupilDto, no de la interfaz, pero así es cómo el automapper construye una lambda:
¿Cómo resolver este problema? Si IncludeBase Automapper con una interfaz no nos conviene (si usa el mapeo en la memoria, no lo afectará), entonces tendrá que abandonar esta API, resolví este problema resaltando el mapeo en el método de extensión , así:
Luego, el mapeador automático encontrará una propiedad de tipo adecuada por nombre, construirá la lambda "correcta"
Gracias por su atencion!