LINQ to SQL (2ª Parte – Definiendo nuestras clases del

modelo de datos)

20 respuestas

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.