Para empezar, recordemos que EF es una ORM (Object Relational Mapping), que en palabras simples es una herramienta de Microsoft .NET que nos permite trabajar con nuestra data en base a un modelo conceptual en vez de tener que interactuar con la data directamente, se basa en el Dominio y no en la Base de Datos, Conexiones o Procedimientos.
Entity Framework
Entity Framework permite a los desarrolladores despreocuparse por el mantenimiento y la codificación necesaria para poder interactuar con cualquier base de datos relacional (Oracle, SQL, MySQL, etc) con un proveedor de datos EF válido.
Inicialmente Entity Framework dependía estrictamente de .NET, pero es a partir de Entity Framework 4.1 en que se separo relativamente, esto quiere decir que aunque todavía se construye sobre .NET, el ciclo de evolución de Entity Framework es independiente al de .NET.
Entity Framework se puede implementar en 3 formas distintas y haciendo simples descripciones: Code First (Si existen clases y no prefieres el diseñador visual), Model First (Si no existe la base de datos y prefieres el diseñador visual) y Database First (Si existe la base de datos y prefieres el diseñador visual). Ahora solo falta decir que en la implementación de Code First, EF5- no soporta la definición de Store Procedures propios para la persistencia de nuestra data con los métodos Insert, Update y Delete.
Inicialmente Entity Framework dependía estrictamente de .NET, pero es a partir de Entity Framework 4.1 en que se separo relativamente, esto quiere decir que aunque todavía se construye sobre .NET, el ciclo de evolución de Entity Framework es independiente al de .NET.
Entity Framework se puede implementar en 3 formas distintas y haciendo simples descripciones: Code First (Si existen clases y no prefieres el diseñador visual), Model First (Si no existe la base de datos y prefieres el diseñador visual) y Database First (Si existe la base de datos y prefieres el diseñador visual). Ahora solo falta decir que en la implementación de Code First, EF5- no soporta la definición de Store Procedures propios para la persistencia de nuestra data con los métodos Insert, Update y Delete.
Rendimiento en Entity Framework 5
Desde la primera versión de Entity Framework, la clase CompiledQuery permitía a los desarrolladores pre-compilar las sentencias Linq para poder mejorar el rendimiento, ya que sin esto cada vez que se ejecutaba Linq, Entity Framework tenia que convertirlo a T-SQL.
Mas usar CompiledQuery tenia 2 grandes inconvenientes, el primero es que se tenia que definir explícitamente qué sentencias se iban a pre-compilar y la segunda era de que no había manera de usar CompiledQuery en DbContext. A esto se suma que si tu estas usando el modelo Code First, lo más probable es que estés usando DbContext y también que Microsoft recomienda que se deberia usar DbContext en nuevos proyectos incluso si estas trabajando con Database First o Model First. En otras palabras, usar CompiledQuery se volvía algo inusual y desconocido.
Entity Framework 5 nos trae auto-compiled queries o auto-cached queries (entiendase lo mismo) lo cual hace que nuestro código Linq se resuelva muy diferente ya que Entity Framework guarda implícitamente en cache el T-SQL generado. Entonces cada vez que se va a ejecuta Linq lo que se hace antes de generar el T-SQL es buscar si existe en cache el T-SQL correspondiente y se utiliza.
Mas usar CompiledQuery tenia 2 grandes inconvenientes, el primero es que se tenia que definir explícitamente qué sentencias se iban a pre-compilar y la segunda era de que no había manera de usar CompiledQuery en DbContext. A esto se suma que si tu estas usando el modelo Code First, lo más probable es que estés usando DbContext y también que Microsoft recomienda que se deberia usar DbContext en nuevos proyectos incluso si estas trabajando con Database First o Model First. En otras palabras, usar CompiledQuery se volvía algo inusual y desconocido.
Entity Framework 5 nos trae auto-compiled queries o auto-cached queries (entiendase lo mismo) lo cual hace que nuestro código Linq se resuelva muy diferente ya que Entity Framework guarda implícitamente en cache el T-SQL generado. Entonces cada vez que se va a ejecuta Linq lo que se hace antes de generar el T-SQL es buscar si existe en cache el T-SQL correspondiente y se utiliza.
Actualizando a Entity Framework 5 & .NET 4.5
Si por algún motivo se empezó a usar EF4 ó EF5 con .NET 4 y se desea hacer un upgrade a EF5 con .NET 4.5 hay que tomar muy en cuenta que las versiones de las .dll referenciadas son diferentes. Entonces cambiar el Target framework del proyecto a .NET 4.5 no es suficiente, ya que la .dll del EntityFramework no se actualiza y hay que hacerlo manualmente.
Entity Framework 5 con .NET 4 |
Entity Framework 5 con .NET 4.5 |
Otros enlaces:
- http://blogs.msdn.com/b/adonet/archive/2012/02/14/sneak-preview-entity-framework-5-0-performance-improvements.aspx
- http://devproconnections.com/entity-framework/improve-performance-entity-framework-5
- http://peterkellner.net/2012/02/15/linq-to-sql-performance-getting-huge-improvement-in-ef5-microsoft-does-listen/
No hay comentarios.:
Publicar un comentario