LINQ to SQL (2ª Parte – Definiendo nuestras clases del modelo de datos)

En la primera parte de la serie de post sobre LINQ to SQL hablé sobre “¿qué es LINQ to SQL?” y vimos por encima algunos escenarios que permite.

En aquél post pusimos unos cuantos ejemplos de código donde demostrábamos cómo mejorar la parte de datos usando LINQ to SQL:

• Cómo consultar una base de datos.
• Cómo actualizar filas en una base de datos
• Cómo añadir y relacionar varias filas en una base de datos.
• Cómo eliminar filas de la base de datos.
• Cómo llamar a procedimientos almacenados.
• Cómo obtener datos con paginación en el servidor.

 Mejoramos todos estos escenarios usando un modelo de clases de LINQ to SQL como éste:

En este segundo post de la serie vamos a ver en más detalle cómo crear el modelo anterior con LINQ to SQL.

LINQ to SQL, el diseñador de LINQ to SQL, y todas las características que estamos viendo saldrán con la versión de .NET 3.5 y en la release de Visual Studio “Orcas”.

Podéis seguir todos los pasos siguientes descargándo tanto Visual Studio “Orcas” Beta 1 o Visual Web Developer Express “Orcas” Beta 1. Podéis instalar las dos y usarlas sin ningún problema con Visual Studio 2005. 

Crear un nuevo modelo de datos LINQ to SQL

Podemos añadir un modelo de datos de LINQ to SQL a un projecto ASP.NET, Class Library o Windows, con la nueva opción “Add New Item” seleccionando “LINQ to SQL”:

Seleccionando “LINQ to SQL” lanzará el diseñador de LINQ to SQL, y nos permitirá modelar las clases que representen una base de datos relacional. También creará una clas fuertemente tipada “DataContext” que tendrá las propiedades que representarán cualquier tabla que modelemos de la base de datos, así como métodos para cada procedimiento almacenado que modelemos. Como describimos en la primera parte de esta serie de post, la clase DataContext es el conducto principal que usaremos tanto para consultar la base de datos como para guardar los cambios que hagamos.

Aquí tenéis una captura de pantalla de un diseño LINQ to SQL ORM vacío, es lo que veréis despues de crear un nuevo modelo de datos LINQ to SQL:

Clases Entidad (Entity)

LINQ to SQL nos permite modelar clases que mapeen una base de datos. Estas clases son típicamente conocidas como “Clases Entidad” (en ingles “Entity Classes”) y a las instancias se las conoce como “Entidades” (en ingles “Entities”). Las clases entidad mapean a tablas de una base de datos. Las propiedades de una clase entidad normalmente mapean las columnas de la tabla. Cada instancia de una clase entidad representa a una fila de una tabla de la base de datos.

Las clases entidad definidas por LINQ to SQL no tienen que derivar de una clase base específica, lo que significa que pueden heredar de cualquier objeto que queramos. Todas las clases creadas por el diseñador de LINQ to SQL se definen como “clases parciales” – con lo que podemos, opcionalmente, añadir propiedades adicionales, métodos y eventos.

A diferencia de la característica de DataSet/TableAdapter que aporta VS 2005, cuando usamos el diseñador de LINQ to SQL no tenemos que especificar qué consultas SQL se tiene que usar cuando creamos el modelo de datos y la capa de acceso.

En lugar de eso, nos centramos en definir las clases entidad, cómo se mapean con la base de datos, y las relaciones entre ellas. La implementación del ORM de LINQ to SQL se encargará de generar la lógica de ejecución SQL por nosotros en tiempo de ejecución para que podamos interactuar y usar las entitades de datos. Podemos usar sintaxis de consultas LINQ para indicar cómo consultar nuestro modelo de datos de forma fuertemente tipada.

Crear clases entidad de la base de datos.

Si ya tenemos un esquema de base de datos definido, podemos usarlo para crear clases entidad LINQ to SQL.

La forma más sencilla de conseguirlo es abrir la base de datos desde el “Server Explorer” de Visual Studio, seleccionar las tablas y vistas (Views) que queramos modelar, y arrastrarlas al diseñador LINQ to SQL:

Cuando añadimos estas dos tablas (Categories y Products) y una vista (Invoices) de la base de datos “Northwind” al diseñador de LINQ to SQL, tendremos las siguientes clases entidad creadas a partir del esquema de la base de datos:

Usando estas clases, podemos ejecutar todos los ejemplos de código (excepto el de procedimientos almacenados) que vimos en la primera parte de esta serie sobre LINQ to SQL. No tenemos que añadir ningún código adicional o configuración para habilitar los escenarios de consulta, inserción, actualización, borrado, y paginación en el servidor.

Nombrado y pluralización

Una de las cosas de las que os daréis cuenta usanto el diseñador de LINQ to SQL es que automáticamente “pluraliza” los nombres de las tablas y columnas cuando crea las clases entidad basádas en el esquema de la base de datos. Por ejemplo: la tabla “Products” del ejemplo se resuelve en una clase “Product”, y la tabla “Categories” se resuelve en la clase “Category”. Este nombrado de clases hace que vuestro modelo sea más consistente con las convenciones de nomenclatura de .NET, y encuentro bastante útil que el diseñador haga esto por mi (especialmente cuando añadimos muchas tablas a nuestro modelo).

Si no os gusta el nombre de una clase o propiedad que el diseñador ha generado, siempre podréis cambiarlo por el que queráis. Podéis hacerlo editanto el nombre de la entidad/propiedad en el mismo diseñador o cambiarlo en la rejilla de propiedades:

Esta habilidad de nombrado de entidades/propiedades/asociaciones es muy útil en un gran número de casos. En particular:

1) Cuando cambie el nombre de una tabla/columna de vuestra base de datos. Como vuestras entidades tendrán nombres diferentes, podéis decidir actualizar las reglas de mapeado  y no el código de vuestra aplicación o las consultas para usar esas nuevas tablas/columnas.

2) Cuando en el esquema de la base de datos tengais nombres que no son “limpios”. Por ejemplo, en lugar de usar “au_lname” y “au_fname” para los nombres de las propiedades en una clase entidad, podéis usar los nombres de “LastName” y “FirstName” en vuestras clases entidad y programar con esos nombres, en vez de cambiarlo en la base de datos.

Relaciones

Cuando arrastremos objetos del “server explorer” al diseñador “LINQ to SQL”, Visual Studio comprobará las relaciones de clave primaria y ajenas de los objetos, y basándose en ellas creará relaciones por defecto entre las diferentes clases entidad que genere. Por ejemplo, cuando añadimos las tablas Products y Categories de la base de datos NorthWind al diseñador LINQ to SQL podemos ver que se ha deducido una relación de uno a n entre ellas (esto se indica con la felcha del navegador):

Esta relación hará que la clase entidad Product tenga una propiedad llamada “Category” que los desarrolladores usarán para acceder a la entidad Category para un Product dado. También hará que la clase Category tenga una colección de “Products” que permitirá a los desarrolladores obtener todos los productos de una Category.

Si no nos gusta cómo el diseñador a nombrado a la relación, siempre podrémos cambiarlo. Sólo hay que hacer clic en la felcha en el diseñador, ver las propiedades y cambiar el nombre.

Retrasar la carga

LINQ to SQL permite a los desarrolladores especificar si las propiedades de las entidades deben precargarse o retrasarse hasta el primer acceso. Podemos personalizar las reglas de precarga/retraso para las propiedades de las entidades seleccionando cualquier propiedad o asociación en el diseñador, y en las propiedades poner la propiedad “Delay Loaded” a true o false.

Por poner un ejemplo, imaginemos la clase entidad “Category” del modelo anterior. La tabla “Categories” de la base de datos “NorthWind” tiene una columna “Picture” que contiene una imagen (potencialmente grande) para cada categoría, y sólo queremos esa imagen cuando vaya a usarla (y no cuando esté haciendo una consulta para obtener los nombres de las categorías en una lista).

Podríamos configurar la propiedad Picture para que se retrase su carga seleccionandola en el diseñador de LINQ to SQL y en las propiedades poner “Delay Loaded” a true:

Nota: Además de configurar el significado de la precarga/retraso de las entidades, podemos sobreescribirlo vía código cuando hagamos consultas LINQ en las clases entidad (lo veremos en el siguiente post de esta serie).

Usando procedimientos almacenados.

LINQ to SQL nos permite modelar procedimientos almacenados como métodos de nuestra clase DataContext. Por ejemplo, supongamos que hemos definido un procedimiento almacenado simple para obtener la información de un producto de un categoryID:

Podemos usar el server explorer de Visual Studio y arrastrar este procedimiento almacenado al diseñador de LINQ to SQL para obtener un método fuertemente tipado que invocará a este procedimiento almacenado. Si lo arrastramos encima de la entidad “Product” en el diseñador, el diseñador declarará que el procedimiento almacenado devuelve un IEnumerable<Product>:

Podemos usar tanto una consulta SQL (que generará una consulta SQL adhoc) o invocar el procedimiento almacenado añadido para obtener las entidades product de la base de datos:

Usar procedimientos almacenados para actualizar/borrar/insertar datos.

Por defecto LINQ to SQL creará automáticamente expresiones SQL apropiadas para cuando tengamos que insertar/actualizar/borrar entidades. Por ejemplo, si escribimos el siguiente código LINQ to SQL para actualizar algunos valores en una instancia de la entidad “Product”:

LINQ to SQL creará y ejecutará una sentencia “UPDATE” apropiada para cuando aceptemos los cambios (Veremos esto en más profundidad en otros post).

Podemos definir procedimientos almacenados personalizados para INSERT, UPDATE, DELETE. Para configurar esto, hacemos clic en una entidad del diseñador LINQ to SQL y en las propiedades de Delete/Insert/Update, en el botón “…”, y ponemos un procedimiento almacenado que ya hayamos definido.

Lo curioso es que el cambio de estas propiedades se está realizando en la capa de mapeo de LINQ to SQL – lo que implica que la actualización del código que vimos ántes sigue funcionando sin tener que hacer ninguna modificación. Con esto libramos a los desarrolladores de que si cambiamos el modelo de datos LINQ to SQL, no tienen que tocar ningún código para que sigua funcionando si deciden poner un procedimiento almacenado personalizado.

Resumen

LINQ to SQL provee una forma limpia de modelar las capas de datos de nuestras aplicaciones. Una vez que tengamos nuestro modelado de datos, podemos realizar de forma eficiente consultas, inserciones, actualizaciones, y borrados sobre él.

Con el diseñador de LINQ to SQL que viene en Visual Studio y en Visual Web Developer Express podemos crear y administrar nuestros modelso de datos para LINQ to SQL extremadamente rápido. El diseñador LINQ to SQL también permite una gran flexibilidad que nos permite personalizar el comportamiento por defecto y sobreescribir/extender el sistema para que se adapte a nuestras necesidades.

En próximos post usaremos este modelo que hemos creado para ver en más detalle los procesos de consulta, inserciones, actualizaciones y borrados. En estos post también veremos cómo añadir validaciones negocio/datos personalizadas a las entidades que hemos diseñado.

Mike Taulty tiene una gran cantidad de videos sobre LINQ to SQL aquí, os recomiendo que los veáis. Así tenéis una forma de aprender viendo cómo se usa LINQ to SQL.

Espero que sirva.

Scott.

Traducido por: Juan María Laó Ramos. Microsoft Student Partner