Antes de la aparición de LINQ, la filosofía de ADO.NET estaba orientada a datos. De este modo, cuando era necesario modificar o eliminar un registro, nuestro afán era detectar la clave primaria de ese elemento y generar, bien de forma estática, bien de forma dinámica, una sentencia UPDATE o DELETE para que la fuente de datos realizase la operación pertinente sobre ella.
La aparición de los mappers objeto-relacionales como LINQ to SQL intentan hacer algo difícil: desterrar ese concepto de nuestra cabeza y obligarnos a pensar exclusivamente en objetos.
Esta diferencia, al implicar un cambio de paradigma, puede resultar duro. Para ilustrar la diferencia entre ADO.NET básico y LINQ to SQL, veamos un ejemplo.
Anteriormente podíamos usar un DataAdapter para mapear una tabla de base de datos dentro de un DataTable. Y era posible, a partir de ese DataAdapter, obtener dos copias de un mismo conjunto de datos, es decir:
//Obtenemos la cadena de conexión de App.config o Web.config
string cadenaConexion = ConfigurationManager.ConnectionStrings["TestDb"].ConnectionString;
// Creamos una conexión a partir de la cadena de conexión
using (SqlConnection conexion = new SqlConnection(cadenaConexion))
{
// Declaramos una consulta
string sqlSelect = "select * from Cliente";
// Abrimos la conexión y generamos un SqlCommand con la conexión y la consulta
// Instanciamos un SqlDataAdapter a partir del SqlCommand
conexion.Open();
SqlCommand commandSelect = new SqlCommand(sqlSelect, conexion);
SqlDataAdapter dataAdapter = new SqlDataAdapter(commandSelect);
//Declaramos dos DataTables y los rellenamos con el DataAdapter
DataTable dt1 = new DataTable();
DataTable dt2 = new DataTable();
dataAdapter.Fill(dt1);
dataAdapter.Fill(dt2);
conexion.Close();
}
Let's code something up! 