EF 4.0 Performance Tips #6

Ya llevamos unos cuantos tips de rendimiento con Entity Framework, por ahora la mayoría se basaban en aspéctos técnicos simplemente, materialización de consultas, consultas parametrizadas, vistas precompiladas etc… En este tip haremos algo distinto, nos centraremos más en como hacemos nuestros modelos de entidades, intentando balancear entre la práctica y las bondades de un diseño de dominio correcto.

Tanto las antiguas como las nuevas capacidades de modelado nos permiten solventar la impedancia de nuestros dominios con respecto a los esquemas relacionales con nuestra base de datos, pero muchas veces estos modelos contienen mucha profundidad de jerarquía y un gran cantidad de relaciones, de forma especial cuando la herencia es TPC-Style.

Lo mejor, como siempre digo, es poner un ejemplo. Imaginaros que partimos del siguiente modelo EDM sobre el cual vamos a ir realizando diferentes acciones para crear un modelo más adaptado a nuestro lenguaje.

Untitled

En este modelo se definen las entidades Producto,Software, Audio, Ebook y Video sobre las que vamos a trabajar y, empezar por ejemplo, a crear nuestra herencia de entidades, disponiendo de un solo root Producto.

 

Untitled2

 

Desde luego este modelo es mucho más comprensible desde el punto de vista de un desarrollador orientado a objetos y seguramente tendrá más sentido para un dominio concreto en el que se encuentre, pero escenarios de modelado como este también suelen producir consultas excesivamente complejas que deberíamos analizar con criterio. Si por ejemplo dado este mecanismo de herencia TPC, pidiéramos por ejemplo una lista de productos, tendríamos que valorar realmente que es lo que estamos solicitando, y esto no es más claro, que la unión de todas las entidades dentro de la jerarquía. Casi prefiero no pegar la sentencia SQL porque alargaría inútilmente el texto de esto post, pero os aseguro que es una delicia verlo pasar en el profiler, y lo ves pasar durante un rato :-).

Después de todo esto, entonces, cual es el corolario que nos queda para este tip??? pues muy sencillo, valorar los modelos de EDM y comprobar la simplicidad o no de las consultas que se generan. Si aún así deseas primar tus modelos de dominio, algo más que aceptable, puedes solventar problemas de consultas por medio de llamadas a ls nuevos métodos de los contextos de trabajo que te permiten escribir directamente el SQL de turno o bien usar procedimientos almacenados ( buff, he dicho yo esto, lo retiro)

 

Saludos

Unai

11 comentarios sobre “EF 4.0 Performance Tips #6”

  1. Gracias Unai por tan grandiosos tips!! Actualmente estoy siguiendo los pasos de la guia de arquitectura de n-capas y realmente estamos en la duda de usar POCOs o STEs. Que crees que sea lo mas conveniente?
    Saludos,
    Raul.

  2. Muy buenos trucos, cuando llegues al numero 12, voy a empezar a pensar que desarrollar con Entity Framework y sin el es mas o menos igual de costoso ..

  3. Raul: no es tan facil la respuesta, depende del escenario que tengas entre manos, si es distribuido o no, si necesitas interoperar etc… hay que resolver algunas preguntas.

    Carlos: No entiendo porque lo dices, al final tips tienes para todo, para los datasets con ADO.NET tradicional etc….. eso no signifique que sea más costoso, sino que como con todo hay que pensar para hacer las cosas :-)…

    Llevo unos dias con ganas de hacerme una camiseta «Please,turn on your brain!» 🙂

  4. La verdad es que Entity Framework no me ha convencido mucho desde sus primeras versiones, pero tengo que reconocer que la 4.0 ya funciona decentemente, sin embargo sigue teniendo muchas limitaciones.

    Al final si quiero usar funcionalidad avanzada de consulta como por ejemplo traerse una jerarquia de empleados, productos etc .. con una sola consulta, usando arboles, tendre que recurrir a procedimientos almacenados.

    Me olvido de picar codigo SQL, pero a cambio tengo que adquirir un conocimiento avanzado de LINQ y entender como el motor de Entity Framework generara las consultas para asegurarme que el acceso a datos sera eficiente, con lo que todas las tareas de profiling y analisis de planes de ejecucion me las sigo comiendo.

    Y para colmo si quiero usar una capa de servicios distribuidos tengo que tener en cuenta que si POCO o STE, si es STE, solo me vale .NET to .NET algo que no suele darse muy a menudo cada vez que anda WCF de por medio.

    Me gustaría probar un dia un ejemplo de servicios WCF que haga uso de entidades POCO con proxys dinamicos y llamarlo desde Java a ver si chuta, si lo hace quiza empiece a verle la utilidad.

    No se Unai, yo es que sigo pensando que para meter EF en un proyecto, hay que operar con bisturi.

    Llamame anticuado, pero prefiero un clio con manual a un polo automatico, asi si me ostio me ostio yo, no me ostia el coche ..

  5. Carlos, la verdad que que la comparacion me ha hecho gracia. A ver todo es un tema de balanza, no solamente te quitas SQL, te quitas mucho más, este es un argumento perezoso porque por ejemplo piensas en modelos de dominio, eliminas impedancia al modelo relacional, facilitas patrones de desarrollo y principios como la ignorancia de la persistencia, y así muchas más.. con esto quiero decir que poner solamente el «me quito SQL» me parece muy pero que muy corto de miras, y te lo digo en el mejor sentido de la palabra no lo tomes a mal claro :-). Ahora claro, decisiones como POCO, STE etc son decisiones que tienes que tomar en funcion de lo que necesites para distribuir tus aplicaciones, de todas formas no veo que problemas tienes con POCO y JAVA y porque crees que te afectan los proxies dinámicos porque a efectos prácticos en la serialización no te afectan. Con respecto a tu ultimo párrafo para operar es siempre necesario un bisturí y adémás siempre es necesario saber como usarlo 🙂

    Saludos
    Unai

  6. A ver .. jajajaja, lo de «me quito el SQL» es uno de los pocos ejemplos que te he puesto de ventajas que tiene usar un ORM ..

    Ya solo por quitarme de picar entidades y mappers merece la pena usarlo .. sin embargo eso es un trabajo que facilmente puede suplir un generador de código .. hace años me pique uno que consultaba los metadatos de una tabla, y generaba la Entidad, el Dao, el Mapper y el repositorio, claro que no era lo bastante listo como para generar consultas como lo hace EF4, pero el arduo trabajo de picarte los métodos CRUD te lo quitabas ..

    Aun asi cuando tocabas el modelo fisico, tenias que tocar el lógico, y eso implicaba modificar SQL’s, entidades y el resto del copon bendito .. cosa que ahora no es necesario con EF.

    Los problemas que tengo con POCO y JAVA son que no los hay .. es decir, a dia de hoy me cuesta encontrar en foros, blogs y resto de parafernalia Web 2.0, gente que se halla picado un servicio WCF que use Entity Framework 4.0 con POCO y se halla tomado la molestia de hacer una prueba de llamada desde Java (que para eso esta POCO), se que en teoria no deberían existir problemas, por que todo el tracking de cambios se genera en el proxy (creo ..), pero los atributos esos raros que hay que poner para resolver tipos de datos dinamicos, me dan mala espina, no se es como una «ñapa» xDDDD.

    Y lo del bisturi .. si, siempre hay que operar con bisturi, y es como todo, hay que saber usarlo .. el problema esta en que no es un producto trivial que puedas aprender a sacarle todo el partido en 3 dias, es decir, «Proyecto nuevo ¡¡, empezamos mañana, oye, por que no usamos EF?, Venga vale ¡¡, esto paso una vez en un proyecto y el equipo termino picando procedimientos almacenados xDDDDD, claro que era la primera versión de EF y funcionaba como el culo.

    Y el problema que veo de fondo es que los libros que hay sobre EF, en general son malisimos, y los ejemplos que ponen son de coña, y no se ajustan en absoluto a los escenarios que te puedes encontrar en el dia a dia, es decir, modelos de datos con mas de 100 tablas, tablas particionadas, consultas recursivas, inserciones masivas usando select, consultas distribuidas ..

    Para terminar una pregunta .. que aconsejas antes de usar Entity Framework en un proyecto, diseñar el modelo lógico de entidades y luego generar la base de datos o viceversa?

  7. Lo de los libros malos no lo dirás por el mio 🙂 :-).
    Con respecto a que te aconsejo, pues ¿con que te sientes más comodo?, lo normal para mucha gente acostumbrada a pensar en el dominio es ni siquiera tener que hacer un modelo, partir directamente del código, algo que el feature pack de EF te permite con Code First. Si te sientes más comodo pensando en tu modelo relacional y despues crear un modelo ( pero que sea un modelo no exáctamente lo que tienes en E-R ) pues adelante… depende como todo de la madurez…

    Saludo
    Unai

  8. Jajaja, no el tuyo todavia no lo he leido, el de Workflows si, claro que cuando tengo que usar Workflows normalmente son maquinas de estados, y prefiero picarme yo mi propia libreria de Workflow que siempre será más liviana que meter WWF, que lo veo mas para MOSS que para un proyecto web donde el flujo son 5 estados.

    Aunque tal y como comentas en tu Tip 7, si esto sigue asi vas a tener que actualizar el libro de Entity Framework para amoldarlo a la version 4, por que con los Tips, STE y POCO ya tienes material para 4 o 5 capitulos xDDDD

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *