LINQ to SQL or Entities, en este momento?

Question

Llego un poco tarde al juego y he decidido dedicar algo de tiempo libre a aprender LINQ. Como ejercicio, voy a reescribir una aplicación WebForms en MVC 2 (que también es nueva para mí). Logré encontrar algunos temas relacionados con LINQ aquí (Learning about LINQ, Beginners Guide to LINQ, Is LINQ to SQL Dead or Alive?), lo que me llamó la atención de Entities vs SQL.

Sin embargo, los hilos tienen más de un año, y parece que no puedo encontrar ninguna información definitiva sobre qué ORM es preferible. ¿Las entidades son más o menos LINQ to SQL 2.0 en este punto? ¿Es aún más difícil de usar?

¿Hay alguna razón para usar LINQ to SQL, o debería simplemente saltar a Entities? Las aplicaciones que escribo en mi actual empleador tienen un largo ciclo de vida (~ 10 años), así que estoy tratando de elegir la mejor tecnología disponible.

Answer 1

En una publicación reciente sobre la extensión de NerdDinner, Scott Hanselman habló sobre esto mismo. Para citar al final:

Conclusión

Hay un montón de opciones para la base de datos Access en .NET. Se encontrará con los lectores de datos en el código antiguo o muy ajustado, pero no hay razón por la que no pueda estar oculto en un repositorio y seguir siendo agradable de usar. LINQ to SQL es bueno, ligero y rápido y tiene docenas de correcciones de errores en .NET 4, pero Entity Framework es la forma en que están dirigiendo en adelante. Plus, Entity Framework 4 es manera mejor que EF 3.5, así que estoy usarlo para ninguna "más grandes que pequeñas" proyectos que estoy haciendo y no estoy teniendo muchos problemas .

concedido No he tenido la oportunidad de jugar mucho con él todavía, pero EF4 parece haberse ganado la confianza de una serie de profesionales.

Answer 2

Sugeriría ir con entidades o NHibernate, Linq acopla muy estrechamente la base de datos a los objetos de su dominio, que luego son utilizados por su capa de presentación. Esto terminará con un acoplamiento estrecho desde la capa de presentación a la base de datos, que tiende a no ser aconsejable.

Personalmente, me gusta Entity Framework 4.0, puede usar consultas linq con él y objetos POCO que codifique usted mismo. Simplemente maneja todo el material de base de datos/SQL por usted.

Answer 3

This article es similar al artículo de Hanselman. Compara el DataReader (al que llaman acceso de datos "conectado"), tipea DataSet ("desconectado"), LINQ to SQL y Entity Framework. Se proporcionan ejemplos de códigos detallados para todos los enfoques, junto con los pros y los contras de cada enfoque.

Answer 4

¿Hay alguna razón para usar LINQ to SQL, o debería simplemente entrar en Entidades?

No soy objetivo (como un usuario de HardqsteSQL rígido), pero esto es responsable.

Las tecnologías de mapeo relacional de objetos son intentos de resolver o mitigar la falta de coincidencia de impedancia relacional entre objetos.Son puentes entre los dos mundos: el mundo de los objetos y el mundo de los datos relacionales.

Y parece que los desarrolladores de estos puentes generalmente llaman a un lado o al otro, a casa.

LinqToSql es un ORM desde el lado del objeto. Fue desarrollado por el equipo C# y le permite usar objetos para representar datos. En LinqToSql no hay cadenas opacas al compilador, todas las consultas son comprobadas por el compilador frente a la asignación.

EF es un ORM desde el lado de los datos. Fue desarrollado por el equipo de ADO y le permite usar datos representados como objetos. En EF, hay muchas cadenas opacas.

Las consultas tienen que ejecutarse finalmente contra una base de datos, y el compilador no puede certificar que la base de datos disponible en tiempo de ejecución coincide con la asignación (verdadera en cualquiera de los ORM). Debido a esta realidad del mundo de los datos, el equipo de datos no valora tanto las garantías del compilador como el equipo de C#.

Después de haber trabajado en un back-end de TSQL durante años, sin la protección de un compilador, valgo mucho la ayuda que el compilador me dará. Y por eso estoy del lado del equipo C# en esto.

---

Por ejemplo, cargar a un cliente con sus pedidos.

//linq to sql. 
DataLoadOptions load = new DataLoadOptions(); 
load.LoadWith<Customer>(c => c.Orders); //<-- strong typed 
myDataContext.LoadOptions = load; 

IQueryable<Customer> query = myDataContext.Customers 
    .Where(c => c.CustomerId == 1); 

    //entity framework 
IQueryable<Customer> query = myObjectContext.Customers 
    .Include("Orders") // <-- opaque string 
    .Where(c => c.Customer.Id == 1); 

Answer 5

Miré a ambas tecnologías muy de cerca a principios de 2009, y he escuchado a muchos de los rumores sobre la "muerte inminente" de LINQ a SQL. Al final, todavía elegí LINQ-to-SQL sobre Entity Framework, porque nunca disfruté trabajando con ADO.NET y EF me lo recordó demasiado, porque estaba tan estrechamente ligado a la base de datos.

En mis proyectos de desarrollo, mi historia ha sido siempre:

1. construir el esquema
2. construir los objetos de base que trabajan con el esquema
3. construir la capa de datos que se comunica con los objetos de la base de datos
4. construir la capa de negocio que se comunica con la capa de datos

con EF, poco iba a cambiar. Con LINQ-to-SQL, pude eliminar completamente el paso 2 para que la capa de datos se comunicara directamente con la base de datos sin tener que preocuparse por las declaraciones de SQL dinámico o las posibles vulnerabilidades de inyección. Además, también obtuve el beneficio de un proceso de administración de cambios mucho más simple durante el ciclo de desarrollo. Realmente no me importa cuál es la posición "oficial" de Microsoft, porque he estado escuchando acerca de la "muerte inminente" de WinForms durante unos cinco años, y todavía está presente.

Microsoft es una empresa, ante todo. Si quieren permanecer en el negocio, le darán al cliente lo que desean o, de lo contrario, el cliente encontrará a otra persona más dispuesta a atender sus necesidades. Si solo para las aplicaciones heredadas que todavía están en uso activo hoy, WinForms será compatible mientras el sistema operativo Windows aún sea compatible con las aplicaciones de Windows 95. En el mismo sentido, LINQ-to-SQL seguirá siendo compatible de una forma u otra. Hasta que pueda combinarse sin problemas con EF, donde las aplicaciones existentes se ejecutarán como se diseñó originalmente (o con la modificación mínima del desarrollador), creo que LINQ-to-SQL también llegó para quedarse en el futuro previsible.