.net - tutorial - ¿Crees que es ventajoso cambiar a Entity Framework?
entity framework homepage (8)
He completado algunos proyectos de MVC en producción con L2SQL bajo el capó y me pareció muy divertido de usar. Ahora me estoy embarcando en un nuevo proyecto y decidí escribirlo usando EF y L2EF dado los artículos previamente citados que proclaman la muerte de L2SQL. Después de solo un par de días, he decidido volver a L2SQL. Cosas simples como tener que establecer claves foráneas para inserciones utilizando la sintaxis terrible que se muestra a continuación o las búsquedas innecesarias me han conmocionado.
foo.Foreign_TypeReference.EntityKey =
new EntityKey("DataContextName.Foreign_Type", "Foreign_Type_Id", ForeignTypeId);
Más bien que:
foo.Foreign_Type_Id = ForeignTypeId;
No creo que sea tan difícil trasladar L2SQL a una versión futura de EF ya que L2SQL tiene un subconjunto de la funcionalidad (aunque mejor implementado). Las pocas cosas que L2SQL tiene que L2EF no tiene, por ejemplo Single () y SingleOrDefault (), se pueden migrar a EF creando algunos métodos de extensión. Creo que tomará mucho menos tiempo ejecutar el sistema usando L2SQL y luego portarlo más tarde cuando EF no sea tan maloliente.
Con LINQ to SQL es probable que no obtenga tanto desarrollo activo como Entity Framework, ¿cree que es mejor cambiar a Entity Framework?
Personalmente, he encontrado que EF es muy torpe y difícil de usar en comparación con LINQ to SQL, que se siente muy natural.
EDITAR: Recientemente publiqué un artículo en mi blog sobre mis sentimientos hacia esta posible decisión ...
LINQ to SQL no parece ser una opción a menos que use SQL Server (o SQL Server compact), por lo que fue motivo suficiente para evitarlo y usar EF (quería usar PostgreSQL).
Definitivamente faltan cosas suficientes en v1 de EF que me harían dudar en recomendarlo. Parece que la versión 2 de EF (cuando se lanzó) sería la primera versión que seria seriamente recomendada para cambiar a.
OMI, no por el momento.
Está claro (especialmente a partir de anuncios recientes ) que EF está atravesando por algunas revisiones pesadas, ya que el escenario " thunderdome " se desarrolla entre LINQ-to-SQL y EF. Pase lo que pase, EF (en algunos años) casi seguro se verá bastante diferente a EF hoy. O ciertamente "lo suficientemente diferente" ;-p
Como tal, mi punto de vista es: quédate con lo simple. Y simple es LINQ-to-SQL.
No veo mucho beneficio aprendiendo un sistema notoriamente complejo si sé que va a cambiar muy pronto.
Y estoy 100% contigo en LINQ-to-SQL ;-p
Si necesitaba algo más que LINQ-to-SQL en este momento, miraría NHibernate o quizás LLBLGen Pro .
( editar - como una actualización, mi posición se ha suavizado un poco, here y here , pero sigo usando LINQ-to-SQL como mi herramienta principal, también - LINQ-to-SQL aún no está del todo muerto ; - pag).
Para el registro, algunas dudas sobre el futuro de LINQ to SQL se han expresado aquí:
Recientemente, tuve que investigar qué proyecto de ORM debería usar. Al principio, intenté L2S. No estaba nada mal, pero ya está obsoleto (MS ya no lo soporta), por eso comencé a probar L2E. Estoy bien con el código generado, pero la creación de vistas falsas, entidades y mapeos entre ellos solo para hacer que el procedimiento almacenado esté disponible para no llenar todos los campos de la entidad fue un exceso para mí. Y quería separar mi capa de acceso a los datos, así que tuve que mapear los datos de los objetos generados a los que hice.
Me tomó algunas horas de experimentación con NHibernate + Fluidez NHibernate + LINQ a NHibernate
para seguir con esta combinación.
Si está realizando un desarrollo basado en bases de datos, EF tiene ventajas reales en la actualidad.
He usado LINQ to SQL y EF y he trabajado a través de las muchas pequeñas frustraciones de EF v1.
Sin embargo, la única cosa que hizo que EF v1 gane para mí es la asombrosamente buena actualización del asistente de la base de datos . Increíblemente, ¡esto realmente funciona ! Puede sonar trivial, pero si está haciendo un diseño de base de datos, quiere confiar en las herramientas para crear sus clases y no quiere tener que regenerar todo su modelo solo para realizar un cambio.
Esto solo hace que EF v1 sea mi elección. Sugiero ignorar las características avanzadas de EF v1, que aún no se puede utilizar como la ambiciosa plataforma que pretende ser.
Preséntate con el chasquido de EF v1 y estarás en la mejor posición para el futuro.
Pete.
Tengo que estar de acuerdo con Marc Gravell. Tal vez cuando se publique la próxima versión de Entity Framework (.net 4.0 / VS2010) habrá una ventaja con el uso de EF, y para entonces probablemente será muy diferente de la versión actual de EF.
Hasta entonces, al menos evitaré EF como la peste por cualquier cosa además de las pruebas / código experimental que nunca llegará a la producción.
El foro EF msdn está lleno de ejemplos de por qué EF no está listo para el horario estelar, pero hay un ejemplo particular que es un ganador claro: lo que normalmente sería una simple consulta de cinco tablas (10-15 líneas de SQL) se convierte en > 1500 líneas de SQL cuando se usa EF y el control EntityDataSource:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3874607&SiteID=1
http://paste-it.net/public/q6ed5c2/
Y en cuanto al futuro de EF: con la historia de Microsoft cambiando de dirección en grandes cosas estratégicas de la noche a la mañana, ¿quién sabe si su actual "objetivo estratégico" con EF se hará realidad dentro de un par de años ...? Estoy seguro de que no apostaría. Ver:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4100399&SiteID=1#4107623
Un buen número de desarrolladores experimentados han otorgado " ADO .NET Entity Framework Vote of No Confidence " como se analiza más adelante here .
Creo que esperamos que se mejore significativamente en .Net 4.0 por parte del equipo de ADO.Net.
Y aquí hay algunos video del reciente PDC.