Entity Framework 4.1 vs Enterprise Data Application Block Rendimiento máximo

Question

Alcance del problema: Deseo utilizar EF4.1 sin ninguna contrapartida a la velocidad y fiabilidad del Enterprise Library Bloque de acceso a datos que conozco y en el que confío.

Gracias a muchos enlaces y blogs de Stackoverflow sobre la optimización del rendimiento de EF, estoy publicando de esta manera, entre muchas otras cosas, para usar EF4.1 que coincida con el rendimiento del bloque de acceso a datos ADO/Enterprise Lib (SqlDataReader).

El proyecto: 1. No linq a Entidades/sql dinámico. Me encanta linq, solo trato de usarlo contra objetos en su mayoría. 2. 100% de los procedimientos almacenados y sin seguimiento, sin fusión, y lo más importante, nunca llame a .SaveChanges(). Simplemente llamo al proc insertar/actualizar/eliminar DbContext.StoredProcName (params). En este punto, hemos eliminado varios de los elementos de desarrollo rápido de EF, pero la forma en que crea automáticamente un tipo complejo para el proceso almacenado es suficiente para mí.

El GetString y métodos similares son una AbstractMapper que simplemente pasa a través de los tipos previstos y arroja el datareader en el tipo.

Así que esta es la marca a batir en lo que a mí respecta. Sería difícil adoptar algo que sé que es más lento.

Eso es más lento !!! ¡Mucho más lento!

Eso es más como él !! Performance Pie Según mis resultados, el pastel de rendimiento debería aumentar la sobrecarga de seguimiento en más del 1% ¡Intenté pre compilar las vistas y nada aumentó tanto como el seguimiento! ¿¿Por qué?? Tal vez alguien pueda hablar sobre eso.

Por lo tanto, este no es realmente justo para comparar con Enterprise Lib, pero estoy haciendo una llamada sin tiempo a la base de datos para cargar los metadatos que entiendo se cargan una vez por grupo de aplicaciones IIS. Esencialmente una vez en la vida de tu aplicación.

estoy usando EF de esta manera con la generación automática almacenado procedimiento utilizado y LINQ a Edmx de importación automática de todos estos nodos de función edmx para asignar a las entidades. Luego genero automáticamente un repositorio para cada entidad y un motor.

Como nunca llamo a SaveChanges, no me molesto en tomar el tiempo para asignar a los procesos almacenados en el diseñador. Toma demasiado tiempo y es fácil romperlo y no saberlo. Así que solo llamo a los procs desde el contexto.

Antes de implementar esto en mi nueva aplicación web de entrega de equipos médicos de misión crítica, agradecería cualquier observación o crítica.

Gracias!

Answer 1

Sólo unas pocas observaciones:

Performance Pie Sobre la base de los resultados de mi ese pastel de rendimiento debe aumentar la sobrecarga de seguimiento por un montón más de 1% Probé pre la compilación de los puntos de vista y nada tiene tan grande de un impulsar como ningún seguimiento! ¿Por qué?

La publicación de blog es de 2008 y, por lo tanto, se basa en EF versión 1 y en EntityObject entidades derivadas. Con EF 4.1 estás usando POCOs. El seguimiento de cambios se comporta de manera muy diferente con POCO. Especialmente cuando un objeto POCO se carga desde la base de datos en el contexto del objeto, Entity Framework crea una instantánea de los valores de propiedad originales y las tiendas se encuentran en el contexto. El seguimiento de cambios se basa en la comparación entre los valores de entidad actuales y los valores de instantáneas originales. La creación de esta instantánea es aparentemente costosa en términos de rendimiento y consumo de memoria también. Mis observaciones son que cuesta al menos 50 por ciento (tiempo de consulta sin seguimiento de cambios es la mitad del tiempo de consulta con cambio de seguimiento). Parece que has medido un impacto aún mayor.

El proyecto: 1. No linq a Entidades/sql dinámica. Me encanta linq, solo trato de usarlo contra objetos en su mayoría. 2. 100% de los procedimientos almacenados y no seguimiento, sin fusión, y lo más importante, nunca llame .SaveChanges(). I simplemente llame al proceso de inserción/actualización/eliminación DbContext.StoredProcName (params). En este punto hemos eliminado varios de los elementos de desarrollo rápido de EF, pero la forma en que crea automáticamente un tipo complejo para el proceso almacenado es suficiente para mí.

Para mí esto parece que está ignorando esencialmente algunas de las características principales por las que Entity Framework existe y es cuestionable por qué quiere usar EF para su propósito. Si su objetivo principal es contar con una herramienta que ayude a materializar resultados de consultas en objetos complejos, puede echar un vistazo al Dapper, que se centra en esta tarea teniendo en cuenta el alto rendimiento. (Dapper es el ORM subyacente utilizado aquí en Stackoverflow.)

Hace unos días recibí una pregunta con excelentes respuestas sobre el rendimiento de EF. Se ha migrado a "programadores" ahora:

https://softwareengineering.stackexchange.com/questions/117357/is-entity-framework-suitable-for-high-traffic-websites