¿Utilizarías LINQ to SQL para nuevos proyectos?

Question

He estado investigando qué capa de datos usar para un nuevo proyecto basado en la 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.

Teniendo esto en cuenta, ¿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

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

LINQ a 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 conceptual y sísmicamente , gran parte de LINQ to SQL es similar a EF, pero cuando te topas con la pared se trata de 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).

Así que .. en fin .. Me lo planteo así:

a) aprender LINQ a SQL como una introducción (ORM a patrones de Microsoft y la tecnología) ..te familiariza con la mayoría de los fundamentos que se comparten con Entity Framework, y una muestra de consulta de estilo LINQ (un gusto adquirido si tienes antecedentes en T-SQL)

b) una vez que tienes un manejar en LINQ a SQL, me gustaría recomendar a saltar sobre el marco de la entidad para conocer los beneficios adicionales (eSQL etc)

c) Poner en marcha un proyecto de prueba de concepto en tanto y comparar los resultados.

Answer 2

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

Answer 3

L2S es, en mi humilde opinión, perfectamente bien de la manera en que es y, como ha 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 4

Salida SubSonic:

http://subsonicproject.com/

Answer 5

creo que los objetivos de la EDM nuestra mucho más grande que las de LINQ a 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 6

IMO, 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 una 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 7

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

Answer 8

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

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 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.

me ha escrito una entrada en hacer el cambio y la comparación de los dos marcos: http://naspinski.net/post/Getting-started-with-Linq-To-Entities.aspx

casi puedo garantizar que va a ser feliz con cualquiera de estos marcos, que son un regalo del cielo 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ña su aplicación correctamente y aísla bien su capa de acceso a datos, debe 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

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

En primer lugar, lo que necesita saber por adelantado es que los objetos DataContext están destinados a durar solamente la unidad de trabajo, punto. 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á a varias personas que recomiendan algunas formas muy muy malas de utilizar 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 desagradable sorpresa que encontré con LINQ es cuando se realiza una actualización desconectada, necesita 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 se puede simplemente pasar un usuario creado en un DataContext diferente y esperar actualización funcione, a menos que establezca DataContext.ObjectTrackingEnabled = false, lo que no lo 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 haya superado algunos problemas molestos (como el anterior), es una gran tecnología y sin duda 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.