Estoy muy emocionado de anunciar la versión preliminar para desarrolladores #1 del proveedor oficial de Linq para Couchbase N1QL. Se trata de un pre-lanzamiento muy temprano para introducir el proveedor, previsualizar su funcionalidad básica e ilustrar cómo usarlo. En este blog, voy a crear una aplicación de ejemplo que repasa los pasos sobre cómo utilizar el proveedor hoy.
Descargo de responsabilidad
Siendo un pre-lanzamiento espera que la API pública cambie significativamente hasta que la beta esté disponible. Ten en cuenta que el proyecto Couchbase.Linq depende de la versión GA del SDK. ¡No utilices este proveedor en producción hasta la versión GA del SDK 2.2.0!
Obtener el paquete
El paquete es una versión preliminar en NuGet y puede encontrarse en aquí. Si utiliza Visual Studio, es probable que desee utilizar el gestor de paquetes NuGet o la consola del gestor de paquetes NuGet para incluir las dependencias en el proyecto.
Primero, crea una aplicación de consola usando Visual Studio. Luego, usando el Gestor de Paquetes, busca Couchbase.Linq:
Asegúrate de seleccionar "Include Prerelease" cuando busques, de lo contrario el paquete no aparecerá en los resultados de la búsqueda. Haga clic en "Instalar" y se instalarán todas las dependencias. Por último, cierra el cuadro de diálogo del Gestor de paquetes.
Configuración e inicialización
El actual proveedor de Couchbase Linq tiene una fuerte dependencia de la clase ClusterHelper de Couchbase .NET 2.1 SDK. El ClusterHelper es una clase que facilita la gestión de buckets y otros recursos que por razones de rendimiento deben ser de larga duración. Es un singleton para un objeto Cluster y un "multiton" para referencias Bucket. Es probable que esta dependencia se elimine en futuras versiones, pero debe tenerse en cuenta cuando se utilice el proveedor Linq en la aplicación.
Para manejar esta dependencia, simplemente tienes que usar el ClusterHelper en tu aplicación y llamar explícitamente a Initialize() exactamente una vez dentro del tiempo de vida de tu aplicación. Por defecto se utilizará localhost para arrancar el cliente, pero puede utilizar la sobrecarga que toma un ClientConfiguration que se puede personalizar a su gusto.
En el gist anterior, creamos una nueva configuración y especificamos una instancia de Couchbase Server instalada localmente como destino de arranque. A continuación, inicializamos el objeto helper del clúster llamando a Initialize y pasando la configuración.
Creación de una instancia DbContext
Una vez que hayas inicializado el ClusterHelper, crearás un objeto DbContext que es una abstracción sobre el almacén de datos subyacente (el Bucket de Couchbase) y proporciona un medio para construir consultas y (pronto) agrupar cambios que serán enviados de vuelta al bucket.
El constructor DbContext toma un objeto Cluster y el nombre del bucket de Couchbase a utilizar en la consulta.
Tenga en cuenta que una vez creado DbContext, se puede utilizar una y otra vez y puede realizar JOINs contra sí mismo también. En un post posterior, mostraré cómo heredar de DbContext para crear objetos de consulta concretos que se asignen a los documentos dentro de tu bucket; eventualmente proporcionaremos soporte de herramientas para generar estos objetos automáticamente desde un bucket.
Creación de una consulta Linq
Crear una consulta Linq no es diferente de usar cualquier otro proveedor Linq en su mayor parte; las diferencias son que Linq2Couchbase soporta palabras clave N1QL y conceptos como NEST, UNNEST y USE KEYS, entre otros.
Como todas las consultas Linq, la ejecución se aplaza hasta que se enumera sobre ella:
Aquí simplemente estamos enumerando la consulta que creamos en el paso anterior. El proveedor tomará la expresión que ha sido generada y la convertirá en una consulta N1QL y la ejecutará devolviendo sólo la porción de filas de la respuesta. Nótese que las excepciones serán lanzadas por el proveedor Linq, lo cual es un comportamiento diferente al del SDK de Couchbase, que devuelve la excepción como una propiedad de la implementación IQueryResult.
¿Y la cláusula WHERE?
¿Se ha dado cuenta de que no especificamos una cláusula WHERE para filtrar por tipo de documento? Dado que los buckets son un keypace de documentos heterogéneos, sin un predicado para filtrar los resultados la consulta generada devolvería cada atributo Name de cada documento dentro del bucket (observe que el bucket de la muestra de cerveza tiene tipos de documento de cerveza y cervecería). Dado que queremos permanecer DRY y añadir un WHERE type="[document-type]" para cada consulta sería tedioso, hay una manera de especificar el filtro de documento como un atributo a la POCO que estamos utilizando para nuestra proyección.
Aquí, en la definición de POCO, hemos añadido un EntityTypeFilter y especificado "beer" como el tipo de documento al que debemos dirigir nuestra consulta. ¡Genial!
Conclusión
Instala el paquete y pruébalo. Háganos saber lo que piensa y si usted encuentra algún error o tiene una solicitud de función, crear un Jira ticket o envíe un pull request!
