Bases de datos

Bases de datos portables (II): Combinando Entity Framework con SQLite


English version here.

En el artículo anterior vimos que es posible hacer uso de ADO.NET para crear una aplicación que utilice SQLite como base de datos. De este modo, con una base de datos local y ampliamente utilizada es posible aumentar radicalmente la portabilidad de nuestra aplicación si ésta no requiere la potencia de una base de datos “tradicional”. Sin embargo, la utilización de ADO.NET de forma directa implica dejar de lado todos los avances que Microsoft ha implementado a lo largo de estos últimos años en materia de mapeo objeto-relacional.

Ya que hemos aprendido a utilizar Entity Framework, ¿por qué no hacer uso de él con SQLite y dejarnos de “picar” código SQL de forma manual? A continuación veremos cómo podemos lograrlo.

(más…)

Bases de datos portables: Utilizando SQLite en una aplicación .NET


English version here.

La mayor parte de las aplicaciones que desarrollamos en .NET de modo profesional suelen implicar la existencia de una base de datos, por norma SQL Server, Oracle, DB2 o MySQL. Sin embargo, algunas veces, pese a necesitar soporte de base de datos, resulta innecesario el montaje y mantenimiento de un gestor de base de datos, bien por portabilidad, bien por licencia, bien porque el volumen de datos y la complejidad de las tablas implicadas no sea muy complejo…

Vimos en artículos relacionados con Android que cada aplicación hace uso de una base de datos SQLite a nivel local. ¿Por qué no aplicar la misma filosofía a una aplicación .NET. Pues bien, es posible encapsular la base de datos en un fichero .db dentro de un directorio local del mismo modo que lo hacen las aplicaciones en Android. Veremos a continuación cómo instalar SQLite para .NET y realizar una pequeña aplicación que realice operaciones CRUD (Create, Retrieve, Update, Delete) sobre una entidad. A partir de ahí, será extrapolable a entidades más complejas.

(más…)

Tutorial de LINQ y Entity Framework


Con el artículo anterior finalizamos con la introducción a LINQ y Entity Framework. A lo largo de esta serie de artículos hemos aprendido desde qué es LINQ hasta su aplicación a objetos, ficheros XML, bases de datos SQL Server y, por extensión, a cualquier otra fuente de datos.

Esta entrada servirá de recopilatorio y puerta de entrada a todo lo que hemos visto acerca de estas tecnologías a lo largo de los últimos días.

  1. Introducción
  2. Construcción de ficheros XML mediante LINQ
  3. Sentencias en LINQ
    1. Selecciones simples. Tipado implícito y tipos anónimos.
    2. Joins y multiselects
    3. Agrupaciones (group by)
    4. Particionado. Delegados y expresiones lambda.
    5. Funciones de agregación (count, sum, average, max, min)
    6. Ordenación (order by)
    7. Operaciones sobre conjuntos
    8. Cuantificadores, generadores y conversores
  4. LINQ to SQL
    1. Mapeo objeto-relacional
    2. Relaciones
    3. Consultas compiladas. Ejecución nativa de SQL. Procedimientos almacenados
    4. Modificación de datos (insert, update, delete)
  5. Entity Framework
    1. Creación de un Entity Model
    2. ObjectContext y Entity SQL
    3. Select, Insert, Update, Delete
    4. Mapeo mediante procedimientos almacenados
    5. Enlazado y desenlazado de entidades. Estados
    6. Entity Model y Data Services

Entity Framework (IV): Mapeo mediante procedimientos almacenados


En el anterior artículo aprendimos cómo mapear un procedimiento almacenado en nuestro Entity Model y hacer uso de él mediante una llamada explícita para eliminar en cascada todos los elementos asociados tanto a los clientes como a los pedidos.

Entity Framework proporciona la opción de personalizar los métodos de inserción, eliminación y actualización a través de procedimientos almacenados, haciendo que éstos se realicen mediante la sintaxis natural de Entity Framework pero permitiéndonos a nosotros indicar, a través de procedimientos almacenados, la forma de hacerlo.

Es importante saber que Entity Framework tiene una política de todo o nada para hacer uso de esta característica, es decir: si se decide utilizar un procedimiento almacenado para realizar las eliminaciones, será obligatorio definir también los métodos de inserción y actualización.

Ya definimos antes un procedimiento para las eliminaciones, llamado sp_Cliente_DeleteCascade. Codificaremos ahora un procedimiento almacenado para realizar las inserciones y otro para las actualizaciones.

El procedimiento de inserción recibirá como parámetros los componentes del registro salvo el identificador, que será generado automáticamente. Además, devolverá como valor de retorno la llamada al método SCOPE_IDENTITY(), que almacenará el valor del IdCliente generado para el registro insertado. A este valor le daremos un nombre para poder identificarlo en nuestro mapeo, por ejemplo, “id”.

(más…)

Entity Framework (III): Select, Insert, Update, Delete


Pese a que LINQ to Entities es bastante parecido a LINQ to SQL, a la hora de trabajar con ambas tecnologías es necesario conocer las diferencias más importantes a nivel práctico (dejaremos los fundamentos teóricos a un lado). Ambas tecnologías tienden a la convergencia, puesto que Microsoft está intentando coger lo mejor de cada una de ellas y adaptarlo a ambos mundos. Sin embargo, siguen existiendo diferencias importantes, especialmente en las primeras versiones de LINQ to Entities.

Select. Carga diferida explícita.

Las primeras versiones de Entity Framework contenían ciertas carencias que, con posteriores actualizaciones, han sido solventadas y corregidas. Una de las carencias más importantes se correspondería con la imposibilidad de las versiones anteriores a 4.1 de realizar una carga automática de los elementos referenciados por un objeto. Es decir, si tenemos el siguiente código:


            // Instanciamos el contexto
            var contexto = new testdbEntities();

            // Lanzamos una consulta
            var clientes = from cliente in contexto.Clientes
                           select cliente;

            // Recorremos los clientes
            foreach (Cliente cliente in clientes)
            {
                Console.WriteLine(string.Format("ID: {0}\tNOMBRE: {1}\tAÑO NAC: {2}",
                    cliente.IdCliente, cliente.Nombre, cliente.FechaNacimiento.Year));

                // Recorremos los pedidos
                foreach (Pedido pedido in cliente.Pedidos)
                {
                    Console.WriteLine(string.Format("\tPEDIDO: {0}\tFECHA: {1}",
                        pedido.IdPedido, pedido.FechaPedido));

                    // Recorremos las líneas de pedido
                    foreach (LineaPedido linea in pedido.LineasPedido)
                    {
                        Console.WriteLine(string.Format("\t\tPRODUCTO: {0}\tCANTIDAD: {1}\tTOTAL: {2}",
                            linea.Producto.Descripcion, linea.Cantidad, (linea.Producto.Precio*linea.Cantidad)));
                    }
                }
                Console.WriteLine(" -----------------------------------------\n");
            }

 

(más…)

Entity Framework (II): ObjectContext y Entity SQL


Una de las mayores ventajas de Entity Framework es que es una tecnología agnóstica respecto a la base de datos que tiene por debajo. Con ADO.NET era necesario utilizar clases específicas para cada base de datos (SqlCommand para SQLServer, OracleCommand para Oracle, etc.). Sin embargo, Entity Framework no se casa con nadie: hace uso de elementos genéricos (EntityConnection, EntityCommand, etc.) que genera instrucciones en un lenguaje intermedio denominado Entity SQL, que es muy similar al lenguaje SQL estándar.

En última instancia, el ADO.NET de toda la vida estará trabajando por debajo, pero Entity Framework establece una capa de abstracción superior que evita la necesidad de atarnos a una fuente de datos concreta. No obstante, es posible descender un poco en el nivel de abstracción y, en lugar de hacer uso de LINQ to Entities tal y como hicimos en el artículo anterior, lanzar directamente consultas sobre el ObjectContext usando para ello Entity SQL.

Dependiendo de la versión de Entity Framework que se esté usando, esto se realizará de un modo u otro, ya que la versión 4.1 introdujo como novedad la utilización del DbContext por defecto, envolviendo el ObjectContext dentro de él.

Por lo tanto, si queremos acceder al ObjectContext del DbContext que el diseñador habrá generado por nosotros, será necesario realizar un casting explícito a IObjectContextAdapter y acceder a su propiedad ObjectContext, tal y como mostramos en el siguiente ejemplo, en el que se ejecuta una sentencia Entity SQL en la que se recuperan todos los clientes de la tabla Clientes.


            // Instanciamos el DbContext
            var dbContext = new testdbEntities();

            // Extraemos el ObjectContext del DbContext (a partir de Entity Framework 4.1)
            var objectContext = ((IObjectContextAdapter)dbContext).ObjectContext;

            // Ejecutamos una sentencia de Entity SQL que recupere todos los clientes
            string sqlQuery = "SELECT VALUE c FROM Clientes AS c";
            var clientes = new ObjectQuery<Cliente>(sqlQuery, objectContext);

            foreach (Cliente cliente in clientes)
            {
                Console.WriteLine(string.Format("ID: {0}\tNOMBRE: {1}\tAÑO NAC: {2}",
                    cliente.IdCliente, cliente.Nombre, cliente.FechaNacimiento.Year));
            }

El nombre de la tabla Clientes está en plural porque es el nombre que recibe la propiedad en la clase de contexto generada por el editor, no porque sea el nombre de la tabla de la base de datos. Recordemos que, Entity SQL realiza consultas sobre entidades, es decir, objetos, no sobre la base de datos.

Nuevamente, comprobamos que la consulta recupera los datos correctamente.

LINQ to SQL (IV): Modificación de datos


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();
            }

(más…)