linq to sql 6
Post on 13-Jun-2015
95 Views
Preview:
DESCRIPTION
TRANSCRIPT
LINQ to SQL (Parte 6 – Obtener datos con
procedimientos almacenados)
9 respuestas
En las últimas semanas he escrito una serie de post sobre LINQ to SQL. Es un ORM integrado en .NET 3.5, y nos
permite modelar bases de datos relacionales con clases de .NET. Podemos usar expresiones LINQ para consultar a la
base de datos, actualiazarla, insertar y borrar datos.
Aquí tenéis los enlaces a los otros post:
Parte 1: Introducción a LINQ to SQL
Parte 2: Definiendo el modelo de datos.
Parte 3: Consultando la base de datos
Parte 4: Actualizando la base de datos.
Parte 5: Enlazar controles de interfaz de usuario con el ASP:LinqDatSource
En estos posts vimos cómo usar expresiones LINQ para obtener programáticamente datos de la base de datos.
En el post de hoy veremos cómo podemos usar los procedimientos almacenados (SPROCs) y las funciones definidas por
el usuario (UDFs) con nuestro modelo LINQ to SQL. El post de hoy veremos el caso de los SPROCs para consultar y
obtener datos de la base de datos. En el siguiente post de esta serie veremos cómo actualizar/insertar/borrar datos con
SPROCs.
¿SPROC o no SPROC? Esa es la cuestión
La pregunta sobre cuando usar el SQL dinámico generado por un ORM en lugar de procedimientos almacenados creando
una capa de datos es causa de debates muy acalorados entre desarrolladores, arquitectos y DBAs. Mucha gente más lista
que yo ha escrito sobre esto, así que no me decantaré ni por un lado ni por otro.
LINQ to SQL es muy flexible, y puede usare para crear un modelo de datos cuyos objetos sean independientes del
esquema de la base de datos, y puede encapsular lógica de negocio y reglas de validación que funcionan tanto si se usa
SQL generado dinámicamente o a través de SPROCs.
En el tercer post de esta serie, hablamos sobre cómo podemos escribir expresiones LINQ contra el modelo de LINQ to
SQL como el siguiente código:
Cuando escribimos expresiones LINQ como esta, LINQ to SQL ejecutará el SQL dinámico necesario para obtener los
objetos de Product que cumplan las restricciones.
Como aprenderemos en este post, también podemos mapear SPROCs en la base de datos con la clase DataContext
generada por LINQ to SQL, que nos permitirá obtener los mismo objetos de Product llamando a un procedimiento
almacenado:
Esta habilidad de poder usar tanto SQL dinámico como SPROCs con una capa de datos limpia es muy útil y nos permite
una gran flexibilidad en nuestros proyectos.
Pasos para mapear y llamar a SPROC con LINQ to SQL
En el segundo post de la serie vimos cómo usar el diseñador LINQ to SQL para crear el siguiente modelo de clases:
Fijaos en las dos partes del diseñador. La de la izquierda nos permite definir el modelo de datos que mapeara nuestra
base de datos. El de la derecha nos permite mapear SPROCs (y UDFs) en nuestro objeto DataContext, que podemos usar
en lugar del SQL dinámico para trabajar con los objetos de nuestro modelo de datos.
Cómo mapear un SPROC en un DataContext de LINQ to SQL
Para mapear SPROCs en la clase DataContext, vamos primero al explorador de servidores de VS 2008 y miramos a los
SPROCs de nuestra base de datos:
Haciendo doble clic en cualquier SPROC se abrirá para edición y podremos ver el código. Por ejemplo, aquí tenéis el
SPROC "CustOrderHist" de la base de datos Northwind:
Para mapearlo en nuestra clase DataContext, lo arrastarmos y soltamos desde el explorador de servidores al diseñador de
LINQ to SQL. Automáticamente se creará un nuevo método en la clase DataContext:
Por defecto el nombre del nuevo método en la clase DataContext será el mismo que el del SPROC, y el tipo de datos
devueltos se creará automáticamente con el siguiente patron: "[NombredelSPROC]Result". Por ejemplo: el SPROC de
arriba devolverá una secuencia de objetos del tipo "CustOrderHistResult". Podemos cambiar el nombre del método
seleccionándolo en el diseñador y cambiarlo en la ventana de propiedades.
Como llamar a un nuevo SPROC mapeado.
Una vez que hemos seguido los pasos para mapear el SPROC en la clase DataContext, es muy fácil de usar. Todo lo que
tenemos que hacer es llamarlo para obtener los resultados fuertemente tipados:
En VB:
En C#:
Además de poder hacer un bucle sobre los resultados, también podemos enlazar los resultados con cualquier control para
mostrarlos. Por ejemplo, el siguiente código enlaza los resultados del SPROC a un control <asp:gridview>
Con lo que mostramos la historia de productos de un cliente:
Mapeando los tipos resultado de los SPROC del modelo de datos
En el SPROC "CustOrderHist" devolvía una secuencia de objetos con dos columnas: el nombre del producto y el numero
total de pedidos que el cliente ha hecho de ese producto. El diseñador LINQ to SQL definió la clase
"CustOrderHistResult" para representar los resultados.
También podemos decidir mapear los resultados del SPROC a una clase de nuestro modelo de datos (por ejemplo: a una
entidad Product o Order).
Por ejemplo, tenemos el SPROC "GetProductsByCategory" en nuestra base de datos que devuelve la siguiente
información:
Como ántes podemos crear un método "GetProductsByCategory" en la clase DataContext que llama a este SPROC
arrastrándolo al diseñador de LINQ to SQL. Más que simplemente arrastrar el SPROC al diseñador, lo arrastraremos
encima de la clase "Product":
Con esto, el método "GetProductsByCategory" devolverá una secuencia de objetos "Product":
LINQ to SQL seguirá los cambios hechos a los objetos que se devuelvan como si fuesen objetos Products obtenidos a
partir de expresiones LINQ. Cuando llamemos al método "SubmitChanges()" todos los cambios hechos a esos objetos se
guardarán en la base de datos.
Por ejemplo, con el siguiente código obtenemos y cambiamos el precio de todos los productos de una categoría
aumentándolo en un 90 %:
Para entender cómo funciona el método SubmitChanges() y el seguimiento que se hace de los cambios, y ver cómo
podemos añadir lógica de negocio a nuestro modelo de datos leed el cuarto post de esta serie.
En el próximo post de esta serie veremos también cómo cambiar el SQL generado cuando
insertamos/actualizamos/borramos datos con SPROCs personalizados. Lo bueno de todo esto es que el código anterior
no habrá que cambiarlo si hemos configurado la clase DataContext para que use SPROCs para las actualizaciones -
Manejando resultados múltiples desde SPROCs
Cuando un procedimiento almacenado puede devolver varios tipos de datos, el tipo de resultado del SPROC en la clase
DataContext no puede ser fuertemente tipado. Por ejemplo, imaginemos el siguiente SPROC que puede devolver un
producto o un pedido dependiendo del parámetro de entrada:
LINQ to SQL permite crear métodos auxiliares para devolver Product o Order añadiendo una clase parcial
"NorthwindDataContext" al proyecto que defina un método (que en este caso llamaremos "VariablesShapeSample") que
invoca al SPROC y devuelve un objeto IMultipleResult:
VB:
C#:
Una vez que añadimos este método al proyecto podemos llamarlo y convetir los resultados tanto a una secuencia de
Product como de Order:
VB:
C#:
Soporte de funciones definidas por el usuario (UDFs)
Además de SPROCS, LINQ to SQL también soporta tanto funciones de usuario de valores y de tablas de valores
(UDFs). Una vez que añadimos un método a la clase DataContext, podemos usar estas funciones en nuestras consultas
LINQ.
Por ejemplo, veamos la función simple "MyUpperFunction":
Podemos arrastrar y soltar desde el explorador de servidores al diseñador de LINQ to SQL para añadirlo como un
método a nuestro DataContext:
Luego podemos usar esta función UDF en expresiones LINQ cuando escribimos consultas contra nuestro modelo LINQ
to SQL:
VB:
C#:
Si usamos el visualizador de debug de LINQ to SQL del que ya hablamos aquí, podemos ver cómo LINQ to SQL
transforma la expresión anterior en una SQL que ejecutará el UDF en la base de datos en tiempo de ejecución:
Resumen
LINQ to SQL soporta poder usar procedimientos almacenados y UDFs contra la base de datos y los integra en nuestro
modelo de datos. En este post hemos visto cómo podemos usar SPROCs para obtener datos y pasarlo entre nuestras
clases del modelo. En el próximo post veremos cómo podemos usar SPROCS para sobreescribir la lógica de
actualización/inserción/borrado cuando llamamos a SubmitChanges() en el DataContext para guardar los cambios.
top related