2008-11-09 31 views
25

Con LINQ to SQL es probable que no obtenga tanto desarrollo activo como Entity Framework, ¿cree que es mejor cambiar a Entity Framework?¿Crees que es ventajoso 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.

EDIT: Me ha publicado recientemente un artículo en mi blog sobre mis sentimientos hacia esta decisión potencial ...

ADO.NET v LINQ to SQL

Respuesta

22

OMI, no por el momento.

Está claro (de recent announcements especialmente) que EF está en 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% con usted en LINQ a SQL ;-P

Si necesitaba algo más de LINQ a SQL en este momento, me vería en NHibernate o tal vez LLBLGen Pro.

(edición - como una actualización, mi posición ha suavizado un poco, y herehere - pero todavía estoy utilizando LINQ a SQL como mi herramienta principal; también - LINQ a SQL isn't quite dead yet; -pag).

+1

Right on !!! Me encanta L2S, y odio semi EF :) (por razones reales y concretas). –

+0

@Timothy - sí, hay razones. Gente como Ian Cooper podía hablar * todo el día * sobre ellos ;-p (buen chico, conoce sus cosas sobre ORM) –

+0

¡De acuerdo, en punto! Cuando EF vNext y .net 4.0 estén fuera, valdrá la pena echar un segundo vistazo. Hasta entonces, L2S ... – KristoferA

2

Para el registro, algunas dudas sobre el futuro de LINQ a SQL se ha expresado aquí:

Is LINQ to SQL DOA?

Has Microsoft really killed LINQ to SQL?

+0

Pero mi punto clave es: si bien hay mucho flujo, invertir mucho es un error. LINQ-to-SQL requiere muy poca inversión, por lo que no veo tanto riesgo. –

+0

Estoy totalmente de acuerdo, Marc. Solo estoy señalando para aquellos que pueden no estar al tanto (como no lo estaba hasta que lo leí recientemente en SO) que LINQ to SQL no está exento de riesgos. Bajo riesgo, y definitivamente altos beneficios a corto plazo, seguro. Puede decir por el volumen de las preguntas de SO que es muy popular – DOK

+0

De hecho. Me encanta la estrategia: matar la implementación que a la gente realmente le gusta ;-p Para ser justo, es mucho más complejo que eso, y espero la respuesta "real" en unos pocos años (.NET 4.0). MS tiene un poco de una montaña PR/dev-confianza para escalar aquí. Espero que tengan éxito ... –

3

Estoy de acuerdo con Marc Gravell. Tal vez cuando se lanza la siguiente versión de Entity Framework (.net 4.0/VS2010) habrá una ventaja al usar 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 algo más que las pruebas/código experimental que nunca llegará a la producción.

El EF msdn forum está lleno de ejemplos de por qué EF no está listo para el horario de máxima audiencia, pero yo soy one particular example que es un claro ganador - lo que normalmente sería una simple consulta de cinco tablas (10-15 líneas de SQL) >1500 lines of SQL convierte al utilizar 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 Microsoft de history of changing direction en cosas grandes estratégicos durante la noche, quien sabe si su actual "s 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

+0

Esa consulta de 1,500 líneas es ridícula. No puedo creer eso. –

+0

Sí, ese tipo de consultas de monstruos son ... sorprendentes. Aquí hay otro ejemplo interesante; consulta simple con agrupación + agregación en dos tablas. L2S genera una consulta eficiente, L2E no. http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/bb72fae4-0709-48f2-8f85-31d0b6a85f68 – KristoferA

2

LINQ a SQL no parece ser una opción a menos que utilice SQL Server (o SQL Server Compact), por lo que fue razón suficiente para que pueda evitarlo y uso EF (quería para 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.

+0

Spot on - l2s SOLAMENTE es SQL Server. EF = otros proveedores –

6

Si realiza un desarrollo basado en bases de datos, EF tiene ventajas reales en la actualidad.

He usado tanto LINQ to SQL como EF y he superado las frustraciones de EF v1.

Sin embargo, la única cosa que hizo que EF v1 gane para mí es la asombrosamente buena actualización desde el asistente de la base de datos. Increíblemente, ¡este 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.

Ponte al día con el chasquido de EF v1 y estarás en la mejor posición para el futuro.

Pete.

+4

¿La "buena" actualización del asistente de la base de datos? ¿El que no detectará si cambia la capacidad de anulación, el tipo de datos, etc. en las columnas existentes? ¿El que reemplaza toda la porción de SSDL del EDMX cuando se actualiza algo, sobrescribiendo las personalizaciones que le haya hecho? – KristoferA

+3

(continuación) ¿El que no puede volver a agregar una entidad eliminada si no utiliza un editor xml para borrar manualmente los artefactos SSDL? Oh, bueno, dicen que será mejor en Visual Studio 2010. Mientras tanto, me estoy apegando a L2S y estoy actualizando mi modelo usando mi herramienta de sincronización para los modelos L2S que aplican cambios * solo *. – KristoferA

7

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); 

En lugar de:

foo.Foreign_Type_Id = ForeignTypeId; 

No creo que sea tan difícil de puerto L2SQL a una versión futura de EF como 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.

+0

Eso lo resume todo para mí. Espero que EF vNext sea más bonita. –

-1

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 + Fluido NHibernate + LINQ a NHibernate
para seguir con esta combinación.

+2

Esto es incorrecto. Microsoft actualmente tiene 5 desarrolladores en LINQ to SQL. –

+0

aha ... Ayer leí que están corrigiendo errores. Mi error. De todos modos, eso no cambia mi opinión. –

+0

.NET 4.0 tendrá un montón de mejoras en LINQ To SQL http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40 –