2009-08-22 21 views
5

He tenido una conversación con un colega sobre "Linq to SQL". Todavía soy nuevo en .NET, así que piensa que necesito aprender más. (Todavía, 30 años de experiencia en programación general deberían contar con mi ventaja, ¿no?) Había leído algunos libros y para un nuevo proyecto decidí usar el Modelo de Datos de Entidades ADO.NET. Mi colega no estuvo de acuerdo porque "sabía" que las entidades tenían muchos problemas. Provocó pérdidas de memoria en el servidor de la base de datos y Microsoft lo suspenderá de todos modos. Él me dijo que debería usar un Módulo de datos en su lugar. Simplemente agregue un .dbml a mi proyecto y use el enlace encima de esto.¿Qué es "Linq to SQL"?

Tiene 5 años de experiencia en .NET, lo que es 4 años más que mi experiencia.

me detuvieron a mí mismo, así que no lo llamaría un imbécil o idiota o lo que sea porque me parece que él cree que "Enlace a SQL" == "Entity Data Model" ...

embargo, Empecé a tener algunas pequeñas dudas. Pensé que Linq to SQL se basa en archivos .dbml, por lo tanto, se basa en modelos de datos. Y he escuchado que Linq to SQL tiene algunos problemas técnicos y que pronto será reemplazado por el modelo de Entity. Si mi colega mezcló estos dos, entonces es un completo imbécil. Pero dado que tiene 5 años de experiencia y como dudo que mi empleado incluso contratara imbéciles, comencé a tener dudas.

Entonces, ¿qué es "Linq to SQL" exactamente?

Respuesta

19

LINQ to SQL y Entity Framework no son lo mismo, sin duda.

Básicamente son ORM diferentes, tanto de Microsoft como de proveedores de LINQ. LINQ to SQL se introdujo con .NET 3.5 y Entity Framework se introdujo en .NET 3.5 SP1.

Es cierto que Microsoft está adelantando el Entity Framework a LINQ to SQL, aunque mucha gente en la comunidad los insta a mejorar LINQ to SQL de todos modos: es un marco más simple que EF. En respuesta, Microsoft ha dicho que tratará de hacer que EF sea más fácil de usar cuando solo se requieren modelos simples.

LINQ to SQL solo funciona contra bases de datos específicas - SQL Server y SQL Server CE, principalmente. Entity Framework es (al menos teóricamente) más agnóstico de la base de datos, por lo que los proveedores de bases de datos pueden conectar sus propios proveedores.

+4

¡Excelente respuesta! Me gustaría abordar la "fuga de memoria" mencionada por el colega de Alex. Los ORM no tienen acceso a la base de datos de ninguna manera especial. Realizan las sentencias SELECT, UPDATE e INSERT como todos los demás, solo convierten los resultados en objetos de su lado (y no en la base de datos). Dado que la base de datos ni siquiera sabría que un ORM está consultando, ¿cómo podría un ORM causar una pérdida de memoria más que otros usuarios? En mi experiencia, las personas conocedoras pueden adivinar, asumir o 'completar' vacíos en su conocimiento (sé que sí), lo que a veces podría llevar a decir cosas inexactas. –

+0

Jon, ¿de verdad tienes un trabajo? Veo que publicas respuestas fantásticas por todos lados, un gran trabajo para la comunidad. –

+0

@Jason: Sí, pero no los sábados :) –

2

Si su amigo estaba sugiriendo que LINQ a Entidades se va, que lo tiene al revés: se continuará con el apoyo

LINQ a SQL pero no extendido mucho en ataque. LINQ to Entities llegó para quedarse y es el marco de acceso de datos preferido de Microsoft para .NET.

+2

+1 ¡Tan importante para esta discusión! – madcolor

+0

+1 de hecho! Además, concluye que mi colega es un imbécil, ya que un desarrollador experimentado de .NET debería saber la diferencia. Oh, bueno ... Pude sacarlo de mi espalda con solo decir que sigo usando entidades, y en ese momento decidió dejar de interferir. –