¿Overkill de Entity Framework es para aplicaciones web?

Question

Digamos que estamos desarrollando una aplicación web de E-Commerce para pequeñas y medianas empresas. Supongamos además que es probable que el negocio aumente con el tiempo. En otras palabras, la línea de productos generalmente crecerá.

Hasta ahora he desarrollado soluciones n-tier utilizando ADO.NET y procedimientos almacenados con la ayuda de la clase SqlHelper. Para aplicaciones más grandes, he usado Enterprise Library (2.0).

Me gustaría avanzar hacia un enfoque basado en ORM y estoy empezando a aprender LINQ, así como a pasar de ASP.NET Web Forms a ASP.NET MVC. No quiero ir con LINQ-to-SQL. La pregunta no es si se requiere un ORM, pero si el ORM del Entity Framework es excesivo para dicho proyecto. No me importa una curva de aprendizaje si está garantizado para la tarea en cuestión.

En cuanto a "una exageración", me gustaría saber si:

• EF es más rápido que una persona con las habilidades correctas de codificación consultas manualmente
• EF lleva a código innecesario hinchazón
• EF innecesariamente escudos desarrolladores de datos a nivel de código de sus consultas
• LINQ a Entidades es adecuado para proyectos de este tamaño

De hecho, si alguien piensa que un ORM es excesivo para dicho proyecto, me gustaría saber por qué.

Answer 1

EF no es excesivo para aplicaciones web.

No estoy de acuerdo con mucho de lo que se menciona en el artículo al que se hace referencia. Estoy de acuerdo con que los desarrolladores deberían tener habilidades decentes con SQL, PERO ORMS hacen un gran trabajo al hacer un trabajo de desarrolladores más rápidamente.

• velocidad de ORMS - Se trata de conseguir mejor todo el tiempo & que le permiten llamar a SP o modificar las consultas para obtener velocidad máxima cuando sea necesario. También hay grandes perfiladores para monitorizar el rendimiento de ORM como EFProf.

• Disminuye el proceso de codificación - ¡¡¡Realmente !!! Una vez aprendido, lo acelera arriba.

• Devs que necesitan saber SQL - Estoy de acuerdo. Sin embargo, los ORMS especialmente con la sintaxis de LINQ a menudo permiten a los desarrolladores escribir más SQL complejo que el que tendrían en .

• Devs escribir consultas eficientes ya - REALLLYYYY !!!! ¡Pregúntele al DBA sus pensamientos! Creo que sí, pero también lo hacen todos los demás. Vea el problema. :-)

• Bloat de código - Tiene que estar en desacuerdo, especialmente con los que tienen LINQ .... A menudo hace que el código sea más legible y reduce el número de líneas a menudo.

• Olvídate de LINQ - Esta nave tiene navegó. LINQ Rocks !!!! Vaya con él o quedarse atrás. No solo se usa en ORMS. Se puede usar en contra, matrices, objetos, XML, archivos, Twitter y la lista sigue y sigue .... Conozca LINQ.

El artículo habla de algunas de las inspiraciones de los últimos desarrollos de MS como procedentes de Ruby on Rails. ROR tiene un ORM basado en Active Record en él .....

ORMS son buenos. No tienen que ser utilizados en todas partes y en todo momento, pero son buenos y deben considerarse.

Answer 2

Definitivamente no es una exageración. Adelante y usa EF.

Answer 3

EF tiene una curva de aprendizaje, pero cualquier cosa nueva lo hace. EF no es exagerado, pero de acuerdo con cualquier sistema que se escriba, use la tecnología adecuada para el proyecto correcto.

Answer 4

Mirando el artículo, la primera cosa que me gustaría ver y estar en desacuerdo con esto es:

Creo firmemente que la moderna web desarrolladores deben:

• Bases de datos de amor.

• Escribe consultas altamente eficientes.

• Minimiza el código.

• Diseñe interfaces de usuario evidentes.

• Trabaja rápidamente.

No estoy seguro de cuántas personas ven el desarrollo web, pero en mi opinión, un devolvedor web debe centrarse en la funcionalidad y las reglas comerciales. La base de datos pura y el código SQL nunca deben ser realizados por alguien de mi equipo que sea más productivo al escribir el código funcional de la empresa.

Aquí es donde entra en juego Entity Framework. Se considera una herramienta de desarrollo rápido de aplicaciones (como la mayoría de otros ORM). Estas herramientas están diseñadas específicamente para permitirle concentrarse más en cómo cumplir los requisitos del usuario y menos en la forma correcta de escribir una consulta.

Dicho esto, también diría que usar la herramienta ingenuamente podría ser peligroso. Cuando utiliza Entity Framework, tiene que ser consciente de las implicaciones de usar el gráfico de objetos que está solicitando.

No es demasiado, la herramienta es muy simple de usar y fácil de aprender. Yo diría que es más fácil "arreglar" un Entity Framework en lugar de arreglar un conjunto de transacción SQL Query raw y ADO.

En proyectos más pequeños, mi recomendación básica es casi siempre ir con algún tipo de ORM. En aplicaciones empresariales, debe ser un poco más cuidadoso y depende completamente del presupuesto :-).

Answer 5

Aunque se trata de una respuesta general desconfiar de cualquier opinión que tiene en estos comentarios:

"herramienta X apesta, escribo en la herramienta de Y y puedo hacerlo más rápido que en la herramienta de X".

O, por supuesto, un hablante de latín habla mejor en latín.

Answer 6

Depende realmente de la complejidad de su modelo de datos en lugar del tipo de aplicación que es.

Si tiene un modelo de datos relativamente simple, EF puede ser excesivo (si aún no lo sabe). Linq-to-SQL puede ser una mejor opción (menos curva de aprendizaje, aunque también tiene limitaciones, como no hay muchas asignaciones).

Si su modelo de datos está más normalizado, en lugar de basarse en la tabla, entonces EF definitivamente dará sus frutos a largo plazo, o nHibernate, o cualquier otro ORM más avanzado.

El artículo al que se vincula parece indicar que los ORM en general son malos, no solo EF. Cuando se enfrenta a sus puntos, parece alejarse de ellos hasta cierto punto. Parece que está tratando de justificar un concepto general (que los nuevos desarrolladores deberían tener que aprender la codificación de bajo nivel, particularmente SQL, antes de ir a marcos de alto nivel) inventando puntos cuestionables.

Answer 7

Un ORM puede ser bastante útil si se usa correctamente y usted comprende lo que está haciendo por usted. Definitivamente debería usar uno, si ya tiene una cierta comprensión del diseño y la consulta de la base de datos.

El objetivo del artículo, principalmente, es que el concepto de no tener que aprender nada sobre el diseño y la consulta de bases de datos de alguna manera hace que su vida sea mejor es una falacia. Prefiero capas muy finas de abstracción entre el código y la base de datos. Siento que eso me permite concentrarme más en la buena experiencia del usuario.

Personalmente siento que la presión detrás de EF está alentando a los nuevos codificadores a ignorar algunos conceptos básicos necesarios. He trabajado con algunos de ellos, y creo que se les hizo un flaco servicio.

Por supuesto, hay algunos que estarán muy en desacuerdo. ¡No hay problema!

Conozco desarrolladores que comenzaron a amarlo, y ahora no. Pero también conozco a desarrolladores que aman a EF y lo juran.

He utilizado EF, LINQ to SQL y NHibernate y otros a lo largo de los años.

Mejor consejo: pruébalo. Ven a tu propia conclusión.

(Divulgación: soy el autor del artículo que ha citado).