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.
Top Related