Diferencia entre Linq a Sql, Linq, conjuntos de datos tipados, ADO.NET

Question

Me he estado preguntando sobre esto por un tiempo. Parece que hay tantas formas ahora que no sé cuándo usar qué? O si hay incluso un punto para aprenderlos. Como si no supiera si básicamente hacen las mismas cosas y simplemente se quedan con una hasta que la dominen, entonces tal vez miren otras.

Así que cuando estaba tomando un curso de ASP.NET que era parte de mi programa.

Primero nos gustó ADO.NET donde simplemente escribimos todo con declaraciones SQL en el código. Luego pasamos a una arquitectura de 3 niveles. Esto se hizo haciendo clases similares y teniendo conjuntos de datos que devuelven cosas.

El SQL se escribió en la clase. Personalmente, nunca me gustó de esta manera, ya que siempre me pareció molesto intentar obtener las citas correctas y, en general, no me gustó.

Luego encontré en el sitio Asp.net su tutorial de 3 niveles de arco que realmente me gustó. Ellos usaban conjuntos de datos tipados. Usted agrega el archivo del conjunto de datos a su carpeta DAL y usted haría adaptadores de tabla y cosas a través de la GUI. Luego escribirías tu código en estas GUI, encontré que era la solución perfecta ya que ahora mi código SQL estaba fuera de mi código y no tenía que preocuparme de las comillas y todas esas cosas no estaban bien o de cerrar las conexiones y cosas más incluso tenía un constructor de GUI SQL!

Luego solo haría un archivo en la carpeta BLL y creare una propiedad para tomar el adaptador de tabla y escribir la lógica de mi capa de negocios.

Lo único que no me gustó fue que, dado que estaba tipeado, si mis cosas intentaban devolver algunas filas nuevas, se enojaba.

Así que cuando tuve que unirme a las tablas usualmente tenía que hacer un nuevo adaptador de mesa.

Ahora parece que hay muchos de ellos.

• Linq -> lo que algunas personas dijeron que reemplazaría ADO.NET y algunos dijeron que no lo haría.
• LINQ a SQL
• ado.net

No estoy seguro de si eso es todo de ellos probablemente no.

Antes de escribir esta publicación, hice una comprobación rápida para ver de qué se trataba el linq a sql y vi algunas publicaciones que decían que MS lo estaba matando. Ellos fueron de 2008, así que no sé si esto es cierto o no, pero me di cuenta de que casi todos los libros de MVC usan como linq a sql, así que no creo que sea así.

¿Vale la pena cambiar a algo diferente y luego a conjuntos de datos tipeados? ¿O cada uno se usa para diferentes situaciones?

Answer 1

LINQ en sí mismo es solo una tecnología base ("Language Integrated Query") que está integrada en C# 3.0 - tiene nada que hacer per se con las bases de datos. LINQ se puede usar contra una variedad de cosas: bases de datos, XML, objetos en la memoria, entidades de Entity Framework, Active Directory, lo que sea.

Linq-To-SQL es la tecnología liviana y directa de MS-SQLServer que le permite utilizar tablas SQL Server de forma fácil y sencilla como objetos reales en su aplicación .NET. Es un "mapeador relacional de objetos" que facilita el manejo de las bases de datos. Solo SQL Server, y Microsoft no lo extenderá mucho más, está disponible, también en .NET 4.0, pero ya no se desarrollará más.

ADO.NET es la tecnología de acceso a datos base en .NET - le da acceso a una amplia variedad de almacenes de datos, relacionales y no relacionales. Es la tecnología más básica: maneja sus datos de una manera cruda y de muy bajo nivel.

Además de eso, tiene los conjuntos de datos ADO.NET, que son un poco como Linq-to-SQL, ya que hacen que sea más fácil tratar con las bases de datos. Contrariamente a Linq-to-SQL, no se trata de los objetos de su modelo de dominio en su código .NET, sino que se trata de las filas y columnas orientadas a la base de datos tal como existen en la base de datos. Es una representación más directa de lo que hay en la base de datos, está en un nivel inferior, está muy unido al diseño de la base de datos, y no es tan "agradable" y fácil de usar como objetos Linq-To-SQL. Usted trata con filas de bajo nivel y columnas y sus valores.

Si tiene la opción en este momento, y no necesita nada más que SQL Server, le recomendaría revisar Linq-to-SQL - la asignación de las tablas de base de datos sin procesar a objetos .NET agradables y fáciles de usar realmente hace tu vida mucho más fácil!

Marc

Answer 2

Yo diría que si usted está teniendo problemas con la obtención de cotizaciones de la derecha en las sentencias SQL utilizando ADO.NET, es probable que la construcción de las sentencias SQL en el camino equivocado. Propenso a SQL injection o al menos: código desordenado.

LINQ to SQL usa ADO.NET para hacerlo. Es una combinación de una herramienta Object-relational mapping (ORM) combinada básicamente con una nueva sintaxis de consulta. No invertiría tiempo en LINQ to SQL ya que Microsoft lo declaró final de su vida útil.

Entity Framework es el reemplazo de LINQ to SQL. Es una herramienta ORM que viene con su propio SQL como lenguaje de consulta, Entity SQL. Puede usar LINQ encima, de modo que la mayoría de las consultas simples sean exactamente las mismas que en LINQ to SQL.

Qué método utilizar depende en gran medida de lo que estás tratando de hacer. No usaría DataSets tipeados (o ningún DataSet realmente). Supongo que es una preferencia personal, pero si puede crear DataSets tipeados, es mejor que realice un mapeo relacional de objetos a escala completa.

Conocer el ADO.NET básico es una habilidad útil, sin embargo lo ves. Especialmente si necesita actualizar múltiples registros en una base de datos sin recuperar primero esos datos, siempre terminará escribiendo sentencias SQL. Recomiendo crear procedimientos almacenados para esos casos, a los que puede llamar con ADO.NET simple, o puede agregarlos a su modelo en Entity Framework y llamarlos allí.

Entity Framework le brinda cierta independencia de la base de datos (a diferencia de LINQ to SQL). Existen implementaciones para Oracle, pero no tengo experiencia con ellos personalmente. Por lo que he escuchado, imponen algunas limitaciones no deseadas si estás haciendo un trabajo semi complicado.

Answer 3

Para aclarar la historia LINQ-to-SQL; no está "muerto", es una parte totalmente soportada del framework .NET, y en desarrollo activo (hay un equipo LINQ-to-SQL en Redmond).

El punto es que el desarrollo de nuevas funciones va principalmente en EF, incluyendo (con suerte) cerrar la brecha entre LINQ a SQL (que en general es muy popular) y EF (que ha sido criticada en muchos de maneras).

Por ejemplo, EF en 4.0 admite objetos POCO, como LINQ-to-SQL.

Personalmente, sigo siendo fanático de LINQ-to-SQL, y felizmente lo usaría para compilaciones nuevas, pero escondería todo esto detrás de una interfaz de repositorio para poder intercambiarlo a voluntad, a cualquier herramienta:

• ADO.NET prima
• LINQ a SQL
• NHibernate
• LLBLGenPro
• Entity Framework

La única cosa que no haría táctil es DataSet ;-P