.net - ¿Usarías LINQ to SQL para nuevos proyectos?

linq-to-sql orm

Question

He estado investigando qué capa de datos usar para un nuevo proyecto basado en web que estoy diseñando y estoy muy interesado en incorporar LINQ to SQL. Su aparente simplicidad, flexibilidad y soporte de diseñador realmente atraen y el vínculo implícito con SQL Server está bien.

Sin embargo, se ha anunciado recientemente que LINQ to SQL quedará relegado al Entity Framework ahora que se ha pasado al equipo de ADO.NET ( http://blogs.msdn.com/adonet/archive/2008/10). /29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx ). Claro, será compatible en el futuro, pero es poco probable que vea mucho más trabajo de desarrollo.

Con esto en mente, ¿me recomendaría usar esta tecnología para mi proyecto o vale la pena seleccionar un ORM alternativo (nHibernate?) O manualmente codificar un DAL genérico.

El proyecto en sí está basado en ASP.NET y SQL Server 2005/2008 y posiblemente use MVC, aunque todavía esté en versión beta. Es un proyecto personal, la base de datos no será demasiado compleja y se usará principalmente como prototipo para ver la tecnología futura de .NET. Sin embargo, basaría proyectos futuros en lo que aprenda de este, por lo que las decisiones que tome afectarán las soluciones más grandes que están por venir.

Y sí, ¡me doy cuenta de que Microsoft probablemente sacará una nueva tecnología de acceso a datos mañana de todos modos! ;)

Answer 1

Creo que los objetivos de EDM son mucho más grandes que los de LINQ to SQL. Si está buscando un ORM simple, entonces creo que LINQ to SQL es el camino a seguir. Si planea construir en clases que tienen una estructura de herencia en relación con las tablas de la base de datos que tienen una estructura relacional y realizan otras asignaciones avanzadas, EDM podría ser una buena opción.

Answer 2

Elija NHibernate. Se mantendrá durante algún tiempo como un concepto o el ORM real. Entonces será útil aprender ambos.

Answer 3

Estoy de acuerdo con Echostorm. L2S es bueno para sus necesidades. Y es bastante fácil trabajar con ...

Answer 4

L2S es, en mi humilde opinión, perfectamente bien tal como es y, como has dicho, no va a ninguna parte. La corporación para la que trabajo se ha convertido en nuestro estándar para el acceso a datos y la usamos para todo, desde pequeñas aplicaciones de 5 usuarios hasta más de 1000 aplicaciones empresariales de usuarios con excelentes resultados.

Answer 5

OMI, todo esto fue realmente desproporcionado.

Microsoft no dijo que LINQ to SQL estaría muerto. Indicaron más que se fusionaría en Entity Framework.

Me centraría en utilizar Entity Framework como solución, sabiendo que gran parte de LINQ to SQL se incluirá en él.

Realmente no hay mucha diferencia en este momento de todos modos. La mayor queja es que Entity Framework no es liviano. ¿Eso realmente importa siempre que tengas buena separación entre tus niveles?

Answer 6

Vale la pena mencionar que este sitio está construido usando LINQ to SQL. Jeff habló sobre usarlo en el podcast de .

Answer 7

Mira SubSonic:

http://subsonicproject.com/

Answer 8

Bueno, está cubierto en su mayoría en respuestas aquí (algunos puntos de vista interesantes también), pero lo voy a decir de nuevo de todos modos ...

LINQ to SQL (L2S) es muy versátil, pero se siente un poco demasiado básico desde mi punto de vista. En la mayoría de los casos, hace un buen trabajo al hacer cosas simples, pero tan pronto como le pides un poco más, se vuelve costoso. Esto no es nada malo. De hecho, creo que LINQ to SQL realmente complementa muy bien el Entity Framework.

Tome Auto Paging con LinqDataSource, por ejemplo. Si no especifica Order By / Group By, entonces es bastante económico. Lanza ordenar o agrupar en la mezcla y comienzas a obtener un aumento en el rendimiento (se vuelve muy hablador). Entonces tienes que escribir tu propia implementación de paginación (que no es terriblemente difícil, lo admitiré).

Seré el primero en admitir que L2S tiene la ventaja sobre Entity Framework en términos de la calidad del T-SQL generado (debería hacerlo, ya que L2S está específicamente diseñado para consultar SQL Server) y conceptualmente y de manera simbólica, gran parte de LINQ para SQL es similar a EF, pero donde te encuentras con la pared está en expandir las necesidades y tener en cuenta los requisitos de implementación más complicados.

Si comenzara de cero y decidiera dedicar tiempo de desarrollo personal, elegiría Entity Framework. Curiosamente, estoy trabajando en un proyecto en este momento que utiliza L2S y está diseñado para escalar y manejar cargas pesadas, pero cuando cumplimos algunos de los requisitos más "creativos", a menudo nos vemos obligados a expandir SQL Metal (por ejemplo, relaciones de muchos a muchos).

Entonces ... en resumen ... me gustaría abordarlo así:

a) aprenda LINQ to SQL como una introducción (a los patrones y tecnología ORM de Microsoft) ... lo familiariza con la mayoría de los fundamentos que se comparten con Entity Framework, y una muestra de las consultas al estilo LINQ (un gusto adquirido si tiene un fondo en T-SQL)

b) una vez que haya manejado LINQ to SQL, recomendaría saltar al Entity Framework para conocer los beneficios adicionales (eSQL, etc.)

c) Implementar un proyecto de prueba de concepto en ambos y comparar los resultados.

Answer 9

L2S es una tecnología increíble, y nunca volvería a la antigua ADO.

Pero como mencionaste, está pasando a segundo plano a L2E. L2S es más que capaz y he realizado numerosas aplicaciones con él y he estado increíblemente satisfecho. Pero al oír que ya no avanzaré, me pondré un cuchillo en el costado. Así que fui a echar un vistazo a L2E y es casi lo mismo cuando se trata de interacción con SQL, y de muchas maneras me resulta más fácil, sin mencionar que es más eficiente con su manejo de relaciones. Con semejantes similitudes, parece lógico elegir L2E.

Escribí una publicación sobre cómo hacer el cambio y comparar los dos marcos: http://naspinski.net/post/Getting-started-with-Linq-To-Entities.aspx

Casi puedo garantizarte que estarás contento con cualquiera de estos marcos, son una bendición para el desarrollo. La simplicidad y la evitación de errores es insuperable. Personalmente me inclinaría a L2E, ya que se desarrollará más agresivamente que en L2S.

Answer 10

Si diseñas tu aplicación correctamente y aíslas bien tu capa de acceso a datos, debes ir con L2S. Por lo que infiero de su publicación, no es un gran proyecto, por lo que L2S debería cumplir con sus requisitos, mientras que el antiguo ADO.NET es simplemente un no-no, y Entity Framework, es ... simplemente no lo use , ¿Okay? De todos modos, si aisla bien su DAL, puede cambiar L2S a otra cosa en el futuro si el proyecto crece. e incluso si L2S no va a ninguna parte, no irá a ningún lado. MS dejó de invertir en él, pero no va a convertirse en obsoleto o algo así, por lo que sigue siendo una inversión segura. Alternativamente, debe evaluar NHibernate, que es simple y maduro.

Answer 11

Utilizo L2S en gran medida en mi proyecto web actual y creo que la colisión más grande que encontrará es la documentación contradictoria con respecto a la mejor manera de hacer el desarrollo de la base de datos n-tier.

Primero y ante todo, lo que necesita saber por adelantado es que los objetos DataContext están diseñados para durar solo tanto como la unidad de trabajo , el período. Además, los DataContext son sin estado. Una vez que se da cuenta de estos dos principios, el uso de LINQ en un entorno n-tier comienza a funcionar bien.

Por otro lado, verás a varias personas recomendando algunas formas muy muy malas de usar Linq. Nunca convierta su DataContext estático, es un error que cometí al principio y funcionó de maravillas hasta que no funcionó, entonces fue absolutamente horrible con cruces de datos incorrectos en diferentes sesiones, etc. En pocas palabras, este es quizás el más grande el no-no más gigantesco de usar Linq y debe escribirse en letras grandes y audaces en cada documento. Además, persistir un DataContext en una variable Session es una idea igualmente mala.

La única otra gran desagradable con la que me encontré con LINQ es cuando se hace una actualización desconectada, necesitas usar el mismo DataContext en toda la llamada. Por ejemplo:

 public static void UpdateUser(UserLibrary.User user) {
using (UserLibraryDataContext dc = new UserLibraryDataContext(_conStr))
{
UserLibrary.User newUser = (from user2 in dc.Users where user2.UserID == user.UserID select user2).FirstOrDefault();
newUser.Email = user.Email;
newUser.FirstName = user.FirstName;
newUser.LastName = user.LastName;
dc.SubmitChanges();
} 

No puede simplemente pasar un Usuario creado en un contexto de datos diferente y esperar que la Actualización funcione, a menos que configure DataContext.ObjectTrackingEnabled = false, que no recomendaría. En cambio, dentro del mismo DataContext debe recuperar el objeto existente, actualizar sus valores y luego enviar los cambios. Mantenga todas las tareas similares dentro del mismo DataContext.

Sin embargo, recomendaría L2S, una vez que supere algunos problemas molestos (como el anterior), es una gran tecnología y definitivamente un ahorro de tiempo. Sin embargo, recomendaría hacer una capa delgada alrededor de su DAL, para que pueda cambiar fácilmente. Estoy considerando (por razones económicas) portar una parte de mi código para usar OpenAccess ORM -> MySql para una parte de mi acceso a datos, y con una capa bien definida, esta tarea solo me llevaría unas pocas horas.