Compartir a través de

Habilitación de un origen de datos para consultas LINQ (Visual Basic)

Hay varias maneras de extender LINQ para permitir que cualquier origen de datos se consulte en el patrón LINQ. El origen de datos puede ser una estructura de datos, un servicio web, un sistema de archivos o una base de datos, para nombrar algunos. El patrón LINQ facilita a los clientes consultar un origen de datos para el que está habilitada la consulta LINQ, ya que la sintaxis y el patrón de la consulta no cambian. Entre las formas en que LINQ se puede extender a estos orígenes de datos se incluyen las siguientes:

  • Implementar la interfaz IEnumerable<T> en un tipo para habilitar las consultas de LINQ to Objects para ese tipo.

  • Crear métodos de operador de consulta estándar, como Where y Select que extienden un tipo, para habilitar consultas LINQ personalizadas de ese tipo.

  • Crear un proveedor para su origen de datos que implementa la IQueryable<T> interfaz. Un proveedor que implementa esta interfaz recibe consultas LINQ en forma de árboles de expresión, que puede ejecutar de forma personalizada, por ejemplo de forma remota.

  • Creación de un proveedor para tu origen de datos que aproveche una tecnología LINQ existente. Este proveedor habilitaría no solo la consulta, sino también las operaciones de inserción, actualización y eliminación y asignación de tipos definidos por el usuario.

En este tema se describen estas opciones.

Cómo habilitar la consulta LINQ del origen de datos

Datos en memoria

Hay dos maneras de habilitar la consulta LINQ de datos en memoria. Si los datos son de un tipo que implementa IEnumerable<T>, puede consultar los datos mediante LINQ to Objects. Si no tiene sentido habilitar la enumeración de su tipo implementando la interfaz IEnumerable<T>, puede definir métodos de operador de consulta estándar de LINQ en ese tipo o crear métodos de operador de consulta estándar de LINQ que extiendan el tipo. Las implementaciones personalizadas de los operadores de consulta estándar deben usar la ejecución diferida para devolver los resultados.

Datos remotos

La mejor opción para habilitar la consulta LINQ de un origen de datos remoto es implementar la IQueryable<T> interfaz. Sin embargo, esto difiere de extender un proveedor como LINQ to SQL para un origen de datos. No hay modelos de proveedor para ampliar las tecnologías LINQ existentes, como LINQ to SQL, a otros tipos de origen de datos disponibles en Visual Studio 2008.

Proveedores de LINQ de IQueryable

Los proveedores linq que implementan IQueryable<T> pueden variar ampliamente en su complejidad. En esta sección se describen los distintos niveles de complejidad.

Un proveedor menos complejo IQueryable podría interactuar con un único método de un servicio web. Este tipo de proveedor es muy específico porque espera información específica en las consultas que controla. Tiene un sistema de tipos cerrado, quizás exponiendo un único tipo de resultado. La mayoría de la ejecución de la consulta se produce localmente, por ejemplo mediante las Enumerable implementaciones de los operadores de consulta estándar. Un proveedor menos complejo podría examinar solo una expresión de llamada de método en el árbol de expresiones que representa la consulta y permitir que la lógica restante de la consulta se controle en otro lugar.

Un IQueryable proveedor de complejidad media podría tener como destino un origen de datos que tenga un lenguaje de consulta parcialmente expresivo. Si tiene como destino un servicio web, podría interactuar con más de un método del servicio web y seleccionar el método para llamar en función de la pregunta que plantea la consulta. Un proveedor de complejidad media tendría un sistema de tipos más completo que un proveedor simple, pero seguiría siendo un sistema de tipos fijo. Por ejemplo, el proveedor podría exponer tipos que tienen relaciones uno a varios recorribles, pero no proporcionaría tecnología de mapeo para tipos definidos por el usuario.

Un proveedor complejo IQueryable , como el proveedor LINQ to SQL, podría traducir consultas LINQ completas a un lenguaje de consulta expresivo, como SQL. Un proveedor complejo es más general que un proveedor menos complejo, ya que puede controlar una variedad más amplia de preguntas en la consulta. También tiene un sistema de tipos abiertos y, por lo tanto, debe contener una amplia infraestructura para asignar tipos definidos por el usuario. El desarrollo de un proveedor complejo requiere una cantidad significativa de esfuerzo.

Consulte también

  • Last updated on