.net - related - select entity framework c#
¿Cuáles han sido sus experiencias con Entity Framework? (3)
Bueno, acabo de terminar de implementar un sistema completo en EF, fue mi primera experiencia real con EF en un entorno de producción. La aplicación se está ejecutando ahora durante aproximadamente 45 días con 100 usuarios golpeándola diariamente sin problemas.
Creo que lo más importante es que tienes que cambiar tu forma de pensar. Si está pensando como una base de datos relacional ORM, entonces ya tiene una mentalidad equivocada. Debe pensar en términos de métodos parciales, objetos y extensiones. Una vez que obtienes esa mentalidad básica, las cosas comienzan a fluir (y reescribes una gran cantidad de código desde la primera vez que comenzaste).
Obtener ayuda es difícil
La otra parte frustrante de EF es que a donde quiera que vayas, la ayuda está llena de gordos de L2S que creen que ya saben todo lo que necesitas hacer y siguen tratando de decirte que lo dejes caer y solo uses L2S ... Si se lo hubiera pedido. cómo hacer eso en L2S, entonces tal vez su opinión sería válida ...
EF funciona bien
La capacidad básica para generar objetos que luego puede extender a través de métodos parciales funciona bien. De hecho, estaba bastante frustrado en las primeras etapas porque seguí tratando de hacer las cosas como lo haría en una SQLCommand. Una vez que se da cuenta de que puede pensar en términos de lo que necesita la lógica de negocios en lugar de cómo funciona SQL, puede hacer mucho más.
Por ejemplo, seguí tratando de hacer uniones para obtener una lista de cosas que fueron relacionadas por un FK específico para varias tareas. Una vez que finalmente descubrí que podía entregar todo el contenido de claus para el EF y deduje cómo recuperar los datos rápidamente, el código era mucho más rápido.
Incluye mal olor
Sin embargo, la sintaxis Include me parece un hack. Tener que usar .Include ("TableName.DetailTable") es feo. Tal vez solo soy mimado por intellisense, pero odio esa sintaxis.
Carga a pedido
Las cargas de detalles maestros también son un poco feas. Si no desea incluirlos, siempre puede tomar su referencia y ver si es .IsLoaded y luego llamar a .Load. ¿Por qué? ¿No puede el objeto hacer eso por mí? Terminé implementando un método de extensión en mis objetos que si trato de cargar una clase de detalle que no está cargada, la carga a pedido. Parece que eso debería haber sido incorporado a mí.
Nota: La carga de detalle de un conjunto de registros filtrado mencionado en la publicación anterior no es complicado, pero tampoco es obvio. Puede filtrar usando expresiones Lambda.
¿Alguna vez quieres mover el proyecto?
Esta es la razón principal: bloqueo sin proveedor. Si alguna vez quiere llevar ese código a otra base de datos, NO PUEDE hacerlo con Linq2SQL. No hay un modelo de proveedor. Puede tener la oportunidad de mover un sistema EF a otro proveedor. En mi caso, el mismo proyecto se ejecuta en SQL Server y VistaDB EF (Alpha) sin cambios de código. De modo que puedo implementarlo en xcopy o conectarme a un servidor como lo elija en tiempo de ejecución.
EF ha estado fuera por un tiempo y estoy considerando evaluarlo. ¿Cuáles han sido tus experiencias?
Estoy interesado en aplicaciones web y de escritorio, y tal vez algunas comparaciones entre EF y otras herramientas ORM que haya utilizado.
La curva de aprendizaje es un factor ya que hay un equipo involucrado. ¿Es esto un desastre hinchado, o es delgado y agudo?
Escuché que Microsoft está usando esto internamente y de una gran manera, por lo que es una buena señal. Si tiene alguna idea acerca de cómo podría encajar en el futuro basado en la nube que MS parece estar gastando su dinero en estos días, eso también podría ser interesante. Después de todo, si esto es algo que eventualmente todos deberíamos saber, eso elevaría el nivel de prioridad un escalón o dos.
¡Muchas gracias!
EDITAR (sí, 3 años después) ... Ya no odio EF ... Entity Framework 4.1 y posteriores son geniales: (finalmente) resuelve todos los problemas / fallas que ha tenido en el pasado. Tenga en cuenta que no "4.0", sino que "4.1" finalmente eliminó el uso feo de "cadenas mágicas", etc. Tiene Contains y todo lo demás más más.
A continuación está mi viejo comentario de 2008
Yo personalmente odio EF. ME ENCANTA LINQ-2-SQL. Aquí están mis advertencias concretas sobre EF:
1) EF no admite la función "Contiene". Entonces, si tiene una tabla de 10,000 ''cuentas'' y desea devolver algunas cuentas que el usuario proporcionó una lista de las ID ... tendría que descargar todas las 10,000 y hacer un ciclo for.
2) EF no es compatible con la carga diferida: http://www.singingeels.com/Articles/Entity_Framework_and_Lazy_Loading.aspx
3) Si tiene una tabla simple "Type", ejemplo AccountType ... y desea seleccionar todas las cuentas de la tabla Cuentas donde AccountTypeID == 9, no hay una manera clara de hacerlo en EF ... EF lo haría oculte ese campo y haga que proporcione una instancia de una clase AccountType.
Todos estos problemas se resuelven en L2S.
EDITAR: Oh, preguntaste "¿Cuáles son tus experiencias ...?" No solo sobre problemas. En mi nuevo trabajo, tienen una base de datos de 205 tablas, más de 600 procedimientos almacenados, etc. Quería cerrar la brecha con el nuevo mundo de la programación ... así que convertí el DAL a un arrastre de 1-1 "todas las tablas en" versión usando EF. Esto es lo que parecía: Gigante EDM
Después de solo 1 semana, tuve que arrancarlo y reemplazarlo con L2S debido a los problemas que mencioné anteriormente, y algunos más.
Después de probar EF para un nuevo proyecto (ASP.Net/ WCF) encontré:
La consulta es muy fácil de implementar a través de LINQ. La mayoría de las veces, el T-SQL generado estaba en el dinero.
El soporte para las aplicaciones de N-nivel era muy deficiente.
La administración de las instancias al contexto del objeto fue igualmente dolorosa en las aplicaciones n-layer, asp.net.
A EF Designer le faltaban algunas características obvias, siempre estaba inmerso en el XML.
Las actualizaciones incurren en costosos recorridos de ida y vuelta de la base de datos o tienen métodos obscenamente oscuros para tratar de evitarlos.
El rendimiento alcanzado fue notablemente notable desde una aplicación n / tier basada en POCO & SP. Esto era esperado, pero no en la medida en que notamos. Incluso después de compilar consultas.
El tiempo que ahorramos en desarrollo debido a la facilidad de las consultas, pronto se perdió tratando de hacer lo que anteriormente eran simples tareas.
Cuando Brain tocó, al referirme al tipo de entidad o nombre de la tabla por cadena era sumamente molesto y me sentía muy desordenado, me encontré escribiendo envoltorios para devolverlos desde un solo punto.
Si desea utilizar una aplicación de capa única, es posible que muchos de los problemas que encontramos no se apliquen.
Pero para nosotros, estamos pendientes de la versión 2 y esperamos algunas mejoras.