c# - EntityFramework VS puro Ado.Net

linq entity-framework

Question

EF es un equipo muy utilizado, pero no me doy cuenta de cómo debería usarlo. Encontré muchos problemas con ef en diferentes proyectos con diferentes enfoques. Entonces, algunas preguntas se juntaron en mi cabeza. Y las respuestas me llevan a usar ado.net puro con procedimientos almacenados. Entonces las preguntas son:

1. ¿Cómo lidiar con EF en la aplicación n-tier? Por ejemplo, tenemos algo de DAL con EF. Vi muchos artículos y proyectos que usaban los patrones de repositorio y unidad de trabajo como algún tipo de abstracción para EF. Creo que ese enfoque elimina la mayoría de los beneficios que aumentan la velocidad de desarrollo y conduce a algunas cosas:
   • la reasignación de la carga de EF da como resultado un DTO que mata el rendimiento (llame a algunos select para obtener datos de tabla - primer bucle, segundo bucle - correlacione los resultados con algún tipo compuesto generado por ef, transfiera los datos mapeados mediante linq y, por último, haga un mapa para algunos DTO). Reasignación exacta a DTO es el asesino de uno de los mayores beneficios efs;
     o
   • conduce a fuertes cohesiones entre EF (y su versión ) y la aplicación. Será algo así como la aplicación de 2 niveles con dal y presentación con bll o dal con bll y presentación. Supongo que no es una buena práctica. Y el mismo proceso de carga que tenemos para la cosa anterior, excepto el mapeo, así que de nuevo surgió el problema de rendimiento. Podríamos tratar de usar EF como DAL sin ninguna abstracción debajo de ellos. Pero obtendremos problemas similares de alguna otra manera.

2. ¿Debo usar un contexto por aplicación / thread / atomic operation? Usar el enfoque: un contexto por aplicación puede aumentar ligeramente el rendimiento y las posibilidades de invocar propiedades de navegación, pero nos encontramos con otro problema: actualizar este contexto y aumentar los datos cargados en contexto. Tampoco estoy seguro de la concurrencia con un dbcontext por aplicación. hilo. Usar el contexto por operación nos llevará a reasignar los resultados de ef a nuestros DTO. Entonces, ven que nuevamente volvimos a la pregunta número 1.

3. ¿Podríamos tratar de usar solo EF + SP? Nuevamente tenemos problemas de preguntas anteriores. ¿Cuál es la razón para usar ef si la mayor parte de la funcionalidad no se usará?

Entonces, sí, EF es genial para comenzar el proyecto. Es muy conveniente cuando tenemos pocas pantallas y operaciones crud. Pero, ¿qué sigue?

Todo este texto es solo pensamientos sin ordenar. Sé que el ado.net puro conducirá a otro tipo de desafíos. Entonces, ¿cuál es tu opinión sobre este tema?

Answer 1

ALHARACA. Net es un marco orientado a objetos que le permite interactuar con el sistema de base de datos (SQL, Oracle, etc.). Entity Framework es una técnica de manipulación de datos en bases de datos como (colección de consultas (nombre de tabla inerte, select * from like this)). se usa con LINQ.

Answer 2

Al seguir las convenciones de nombres, encontrará que se llama: ADO.NET Entity Framework, lo que significa que Entity Framework se encuentra encima de ADO.NET, por lo que no puede ser más rápido. Puede funcionar en igual tiempo, pero echemos un vistazo a EF proporciona:

• Ya no tendrá que preocuparse de escribir consultas sin ninguna pista sobre si lo que está escribiendo se compilará o no.
• Hace que confíe en C # o en su lenguaje .NET favorito al escribir sus propias restricciones de datos que desea aceptar del usuario objetivo directamente dentro de sus clases modelo.

Finalmente: EF y LINQ le dan mucha potencia para mantener sus aplicaciones más tarde.

Hay tres modelos diferentes con Entity Framework: Model First, Database First y Code First conocen cada uno de ellos.

-El punto sobre matar el rendimiento cuando la reasignación está en proceso, es porque en la primera ejecución, EF carga metadatos en la memoria y eso lleva tiempo ya que construye una representación en memoria del modelo del archivo edmx.