asp.net - mvc - entity framework netcore
¿Es Entity Framework Overkill para aplicaciones web? (7)
Digamos que estamos desarrollando una aplicación web de comercio electrónico para una pequeña o mediana empresa. Supongamos además que es probable que el negocio crezca con el tiempo. En otras palabras, la línea de productos normalmente crecerá.
Hasta ahora he desarrollado soluciones de n niveles 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 hacer el cambio 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 sino si el ORM de Entity Framework es una exageración para tal proyecto. No me importa una curva de aprendizaje si está justificado para la tarea en cuestión.
En lo que respecta a "exceso", me gustaría saber si:
- EF es más rápido que alguien con las habilidades correctas que codifican las consultas manualmente
- EF lleva a un código innecesario
- EF protege innecesariamente a los desarrolladores de los detalles a nivel de código de sus consultas
- LINQ-to-Entities es adecuado para proyectos de este tamaño
De hecho, si alguien piensa que un ORM es una exageración para tal proyecto, me gustaría conocer las razones.
Aunque esta es una respuesta general, desconfíe de cualquier opinión que tenga estos comentarios en:
"La herramienta X apesta, escribo en la herramienta Y y puedo hacerlo más rápido que en la herramienta X".
O por supuesto un hablante de latín habla mejor en latín
Definitivamente no es una exageración. Adelante, usa EF.
EF no es una exageración para las aplicaciones web.
No estoy de acuerdo con mucho de lo que se indica en su artículo de referencia. Estoy de acuerdo en que los desarrolladores deben tener habilidades decentes con SQL BUT ORMS hacer un gran trabajo para hacer un trabajo de desarrolladores más rápido.
Velocidad de ORMS: están mejorando todo el tiempo y le permiten llamar a SP o modificar las consultas para obtener la máxima velocidad cuando sea necesario. También hay excelentes perfiladores para monitorear el desempeño de ORM como EFProf .
Ralentiza el proceso de codificación - ¡¡¡En serio !!! Una vez aprendido, se acelera.
Los desarrolladores necesitan saber SQL - estoy de acuerdo. Sin embargo, ORMS, especialmente con la sintaxis de LINQ, a menudo permite a los desarrolladores escribir SQL más complejo de lo que lo harían por sí mismos.
Los desarrolladores ya escriben consultas eficientes - REALLLYYYYYY !!!! ¡Solo pregúntale a la DBA sus pensamientos! Resulta que creo que sí, pero todos los demás también. Ver el problema. :-)
Bloqueo de código: hay que estar en desacuerdo, especialmente con los que tienen LINQ ... A menudo hace que el código sea más legible y reduce el conteo de líneas a menudo.
Olvídate de LINQ - Esta nave ha navegado. LINQ Rocks !!!! Ir con ella o quedarse atrás. No solo se utiliza en ORMS. Se puede utilizar en contra, matrices, objetos, XML, archivos, twitter y la lista sigue y sigue ... Conozca LINQ.
El artículo habla sobre la inspiración de los últimos desarrollos de MS que provienen de Ruby on Rails. ROR tiene un ORM basado en Active Record en él .....
Los orms son buenos. No tienen que ser usados en todas partes y en todo momento, pero son buenos y deben ser considerados.
EF tiene una curva de aprendizaje, pero cualquier cosa nueva tiene. EF no es una exageración, pero de acuerdo con cualquier sistema escrito, use la tecnología adecuada para el proyecto correcto.
En realidad, depende de la complejidad de su modelo de datos en lugar del tipo de aplicación que sea.
Si tiene un modelo de datos relativamente simple, entonces EF puede ser una exageración (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 asignaciones de muchos a muchos).
Si su modelo de datos está más normalizado, en lugar de solo basado en tablas, 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 retroceder hasta cierto punto. Parece que está tratando de justificar un concepto general (que los nuevos desarrolladores deberían tener que aprender codificación de bajo nivel, particularmente SQL, antes de ir a marcos de alto nivel) inventando puntos cuestionables.
Mirando el artículo, lo primero que vería y no estaría de acuerdo es lo siguiente:
Creo firmemente que los desarrolladores web modernos deben:
• Love bases de datos.
• Escribir consultas altamente eficientes.
• Minimizar código.
• Diseñar interfaces de usuario evidentes.
•Trabaja rapido.
No estoy seguro de cuánta gente ve el desarrollo web, pero en mi opinión, un desarrollador web debería 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 sería más productivo al escribir código funcional de negocios.
Aquí es donde Entity Framework entra en juego. Se considera una herramienta de desarrollo rápido de aplicaciones (como lo son la mayoría de los otros ORM). Estas herramientas están diseñadas específicamente para permitirle enfocarse más en cómo cumplir los requisitos del usuario y menos en cuál es la forma correcta de escribir una consulta.
Dicho esto, también diría que usar la herramienta ingenuamente podría ser peligroso. Cuando usa Entity Framework, todavía tiene que ser consciente de las implicaciones de usar el gráfico de objetos que está solicitando.
No es una exageración, la herramienta es muy fácil de usar y fácil de aprender. Yo diría que es más fácil "arreglar" un Entity Framework en lugar de arreglar una consulta SQL sin procesar y un conjunto de transacciones ADO.
En proyectos más pequeños, mi recomendación básica es casi siempre ir con algún tipo de ORM. En las aplicaciones empresariales, debe ser un poco más cuidadoso y depende completamente del presupuesto :-).
Un ORM puede ser muy útil, si se usa correctamente y usted entiende lo que está haciendo por usted. Definitivamente debería usar uno, si ya tiene algún conocimiento del diseño y la consulta de la base de datos.
El punto del artículo, principalmente, es que el concepto de no tener que aprender nada sobre el diseño de bases de datos y las consultas de alguna manera hace que tu 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 centrarme más en la buena experiencia del usuario.
Personalmente, creo que la prensa detrás de EF está alentando a los nuevos programadores a ignorar algunos conceptos básicos necesarios. He trabajado con algunos de ellos y creo que fueron perjudicados.
Por supuesto, hay aquellos que estarán muy en desacuerdo. ¡No hay problema!
Conozco a los desarrolladores que empezaron a quererlo, y ahora no. Pero también conozco a los desarrolladores que aman a EF y juran por ello.
He usado EF, LINQ to SQL y NHibernate y otros a lo largo de los años.
El mejor consejo: pruébalo. Llegue a su propia conclusión.
(Revelación: Soy el autor del artículo que citó).