Creo que son ya unas cuantas entradas las que llevo con EF 6 en este blog, y eso que aún no tenemos ni la primera CTP, pero a cada nueva build que hacen podemos ver nuevas e interesantes cosas que me gusta adelantarme a escribir.

 

De entre estas nuevas cosillas me gustaría destacar estos tres nuevos métodos que he podido contribuir en sus correspondientes pull request ( addrange, removerange, haschanges )

 

AddRange

 

Como seguramente os imaginaréis, este pequeño método nos permite agregar dentro de nuestros DbSet<T> y DbSet un conjunto de elementos de una única pasada, evitando así tener que hacer las n repetitivas llamadas al método Add. Aunque esto parezca trivial, y en realidad, fuera fácil de construir con un método extensor, la verdad es que tiene un pelín más de miga, puesto que algo que podíamos hacer era aprovechar este nuevo método para evitar la detección de cambios para cada uno de los elementos de la colección a incluir.

Nota:

Como seguramente sabréis, EF realiza un proceso de detección de cambios de forma automática ( si no hemos configurado lo contrario ) en ciertos procesos, como por ejemplo en el de agregar elementos al DbSet, por lo tanto, esto podría suponer una sobrecarga en ciertos escenarios con muchas entradas en el ObjectStateManager. Si quieres saber más sobre la detección de cambios en EF, entonces nada mejor que leer del mejor, en concreto, esta serie de Arthur Vickers.

 

Al final, una vez valorado esto y agregado este nuevo método en la superficie publica de DbSet<T> y DbSet, el código queda tan liviano como vemos a continuación en el método AddRange de nuestro InternalSet.

RemoveRange

 

Bien, después de explicado lo anterior, este es de cajón, en realidad aplican los mimos argumentos con respecto a relajar la detección de cambios, por lo tanto, la implementación en nuestro InternalSet es similar a lo siguiente:

 

HasChanges

 

Este método es una pequeña ayuda para comprobar si nuestra unidad de trabajo tiene cambios pendientes, elementos agregados, borrados o modificados en la misma y no llevados aún a la base de datos. El mismo está situado en la clase DbChangeTracker y como podemos ver en el siguiente tests funcional lo tendremos accesible mediante la propiedad ChangeTracker de nuestros DbContext.

 

 

La implementación es realmente sencilla puesto que internamente ya se dispone de un método para comprobar el número de entradas en el ObjectStateManager.

 

Para terminar esta pequeña entrada me gustaría hablar de otra “gran” novedad que tenemos en las últimas builds de EF, novedad introducida por el propio equipo, en concreto por Andrew Peters (@anpete), que consiste en la posibilidad de hacer el scaffolding de las entidades mapeadas con procedimientos almacenados de forma automática. Lo mejor para explicarlo es ver un pequeño ejemplo, para ello partiremos del siguiente modelo y su correspondiente configuración:

 

Nada nuevo, o por lo menos de lo que no hayamos hablado ya, una entidad mapeada con procedimientos almacenados por medió del método MapToStoreProcedures, aplicando convenciones al no estar “configurado”. Lo nuevo en las últimas builds, le recomiendo usar los paquetes de NuGet del feed de ASP.NET Stack nightly builds, está en que las migraciones son capaces de hacer el scaffolding de estos procedimientos almacenados, por lo tanto, si ejecutaramos la creación de una migración, tal cual sigue:

 

Veríamos un resultado similar a lo siguiente:

¿Qué os parece?

 

Saludos

Unai