Entity Framework vs Direct Data Access

Question

Siempre he usado acceso directo a datos para tratar objetos en el pasado (manualmente ejecutando una consulta y mapeando los resultados en objetos de datos). Sé que Microsoft actualmente está presionando EF para que sus clientes lo utilicen para consultar objetos de datos.

Tengo algunas preguntas para la comunidad con respecto a esto: -

• Si usted tiene una base de datos compleja, es decir, un par de cientos de mesas, una buena cantidad de procedimientos almacenados, vistas, todo está en 3NF. ¿La carga de gestionar dos esquemas (un mapeo de esquema de EF local y un DB) compensa el intercambio?

• Una vez que comienza a aumentar el acceso a los datos, ¿cómo se compara el almacenamiento en caché en los dos? Sé que en Acceso directo puede implementar cualquier forma de almacenamiento en caché que desee, ¿EF permite algo similar?

• Teniendo en cuenta la historia de Microsoft de matar productos después de presionarlos fuertemente y hacer que la gente escriba para ellos (SQL-NS, Linq-to-Sql) ¿cómo es que le puede pasar esto a EF?

Como ya he dicho que estoy actualmente en gran medida el uso de acceso directo en el momento, pero teniendo en cuenta una migración (es decir, con nuevas consultas en el futuro, no dar marcha atrás en todos ellos por el momento), y fue en busca de asesoramiento de la resto de la comunidad en sus puntos de vista.

Answer 1

Si usted tiene una base de datos compleja, es decir, un par de cientos de mesas, una buena cantidad de procedimientos almacenados, vistas, todo está en 3NF. ¿Es la carga de administrar dos esquemas (un mapeo de esquema EF local y un DB) que vale la pena compensar?

Puede utilizar herramientas automatizadas para mantener su esquema EF actualizado, por lo que no es realmente tan malo.

Una vez que empiece a aumentar el acceso a los datos, ¿cómo se compara el almacenamiento en caché en los dos? Sé que en Acceso directo puede implementar cualquier forma de almacenamiento en caché que desee, ¿EF permite algo similar?

Por lo que yo sé, sí.

Dada la historia de matar productos después fuertemente empujándolos y hacer que la gente a escribir para ellos de Microsoft (SQL-NS, LINQ-to-SQL) Cómo likley es que esto suceda a EF?

Esta pregunta es demasiado hipotética.

El problema que estoy teniendo con EF es su rendimiento. Sí, obtienes un desarrollo rápido, pero intercambiando rendimiento. Con EF es realmente fácil escribir un código malo y lento, y si no sabe al 100% lo que está haciendo, puede terminar con graves problemas de rendimiento más adelante (especialmente si se trata de cientos de tablas) .

Lo que sugeriría es probar algunos marcos Micro-ORM, como Dapper o Massive. No sacrificas tanto rendimiento, pero es más fácil de mantener que el enfoque Ado.net tradicional.

Pero hey, ese soy yo, te puede encantar EF.

Answer 2

Lo que se debe tener en cuenta con EF o cualquier otra herramienta ORM es que simplemente convierta algo (árboles de expresión Linq en el caso de EF y Linq2Entities) en sentencias SQL. Como hay una capa adicional de abstracción y análisis allí, siempre será más lento que la consulta directa. Sin embargo, generalmente es más fácil para un desarrollador usar un ORM. Afortunadamente, la mayoría de los ORM (no estoy seguro acerca de EF en particular) proporcionan alguna manera de seguir ejecutando consultas directamente cuando sea necesario.

Menciona tener una base de datos "complicada", y eso generalmente significa tener consultas complicadas. Eso es algo que a Linq realmente no le gusta. Por ejemplo, si termina teniendo consultas que unen 13 tablas, y casi cada columna devuelta se pasa a una función db, y tiene un montón de declaraciones de casos, y un grupo de sub-selecciones, entonces es casi imposible de traducir a Linq . Lo más fácil de hacer es ajustar esa complejidad en una vista y usar EF para solo consultar la vista.

En el lado positivo, EF proporciona al desarrollador intellisense, ya que las clases reales están diseñadas para imitar a la base de datos. Dependiendo de cómo se diseñen sus elementos EF, puede configurar su proyecto de forma que todas las clases se generen a partir de la base de datos, de modo que si alguien edita el esquema DB o cambia el tipo de datos de una columna, su código C# ya no compila Con las consultas SQL directas tradicionales, nunca se descubre eso hasta el tiempo de ejecución (o el tiempo de prueba de integración).

Son todos los intercambios ... IMO lo mejor que puede hacer es probar ambos y ver cuál le gusta más, o diseñar una solución de tal manera que proporcione cualquiera de las opciones. En la última aplicación en la que trabajé, tenía una clase de "fábrica de bases de datos" (patrón de fábrica) que usarían las otras clases de acceso a datos, y podían pedirle a la fábrica un objeto de comando antiguo ADO.NET o solicitar el Objeto ORM (el contexto en el caso de EF, pero estaba usando SubSonic, por lo que en su lugar era una implementación de IQueryable). De esta forma, puede hacer consultas "simples" a través de EF y consultas "complejas" en SQL.

Answer 3

El principal beneficio de EF en comparación con el acceso directo a datos es la productividad del desarrollador.

Muy pocos desarrolladores escriben código de ensamblaje, dejamos que el compilador lo genere. A medida que las herramientas como EF mejoran las usaremos más y dejaremos de escribir SQL.

Sin embargo, a veces necesita el control adicional para obtener el rendimiento requerido, por lo que aún puede necesitar escribir algún código SQL. Al igual que todavía hay un código de ensamblaje que se está escribiendo.

La conversión de una solución que funciona no tiene ningún valor comercial. Podrías probar EF para un nuevo desarrollo.