Esta versión es la versión GA oficial del soporte .NET Core para el SDK .NET de Couchbase. .NET Core es la última encarnación del framework .NET y se describe como "NET Core es una plataforma rápida, ligera y modular para crear aplicaciones y servicios web que se ejecutan en Windows, Linux y Mac".
Espera un momento... lee eso otra vez: ".NET Core es una plataforma rapidísima, ligera y modular para crear aplicaciones y servicios web que funcionan en Windows, Linux y Mac“. ¿Aplicaciones Microsoft .NET funcionando en OSX y Linux? ¿En qué mundo bizzaro vivimos? Seguro que es la "nueva" Microsoft.
En esta entrada del blog, voy a repasar lo que está en la versión 2.4.0, los cambios en el empaquetado (NuGet), y qué versión de .NET soporta el SDK. También demostraremos algunas de las nuevas características como Datastructures.
¿Qué contiene esta versión?
2.4.0 es una gran versión con más de 30 commits. Si tenemos en cuenta que hemos publicado 3 versiones preliminares para desarrolladores antes de la versión 2.4.0, en realidad hay muchísimas más confirmaciones que han precedido a esta versión en los últimos 6 meses. He aquí una visión general de algunas de las características más impresionantes - se puede ver todos los commits en la sección "Notas de la versión" a continuación:
Compatibilidad con .NET Core
Por supuesto, la característica más significativa de la versión 2.4.0 es la compatibilidad con .NET Core, lo que, según el párrafo inicial, significa que ahora se puede desarrollar en Mac OS o Windows y desplegar en Linux (o viceversa, pero las herramientas aún están un poco inmaduras). Se trata de un gran cambio para el desarrollador tradicional de Windows.
Si no conoce .NET Core, puede leer más sobre él en la página Sitio web de .NET Core. Lo mejor de todo es que es de código abierto (Apache 2.0) y el código fuente está disponible en Github.
El SDK de Couchbase soporta específicamente el netstandard1.5 o superior. Hemos probado el SDK utilizando 1.0.0-preview2-1-003177 de las herramientas de línea de comandos.
Cambios en los envases
Al igual que las tres versiones preliminares para desarrolladores, el paquete NuGet contendrá binarios tanto para .NET Full Framework (orientado a .NET 4.5 o superior), como para .NET Core (orientado a .NET Core 1.1). Dependiendo del proyecto de destino para el que incluya la dependencia, se utilizarán los binarios correctos.
Así, si su proyecto de Visual Studio es una aplicación .NET Full Framework mayor o igual que 4.5, obtendrá los binarios para la versión full framework de .NET. Del mismo modo, si su aplicación es una aplicación .NET Core, se utilizará la versión .NET Core de los binarios. No debería tener que hacer nada para habilitar esto.
La versión .NET 4.5 más antigua de los paquetes ya no se publicará; 2.3.11 es la última versión compatible de la serie 2.3.X.
MS Logging para Core
Para .NET Core hemos decidido pasar de utilizar Registro común a MS Logging principalmente porque ninguna tercera parte (log4net por ejemplo) tienen soporte estable para .NET Core en este momento.
Además, al pasar de Común.Registro a MS Logging hemos eliminado una dependencia más de terceros - lo que siempre es agradable. No es que Common.Logging no fuera suficiente, pero tiene más sentido utilizar una dependencia de Microsoft.
A continuación se muestra un ejemplo de configuración del cliente 2.4.0 orientado a .NET Core y utilizando NLog:
Primero añade las dependencias al project.json:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
{ "version": "1.0.0-*", "buildOptions": { "emitEntryPoint": verdadero, "copyToOutput": { "incluir": [ "config.json", "nlog.config" ] } }, "dependencias": { "CouchbaseNetClient": "2.4.0-dp6", "NLog.Extensions.Logging": "1.0.0-rtm-beta1", "Microsoft.NETCore.App": { "tipo": "plataforma", "version": "1.0.1" }, "Microsoft.Extensions.Logging.Debug": "1.1.0", "Microsoft.Extensions.Logging": "1.1.0" }, "marcos": { "netcoreapp1.0": { "importaciones": "dnxcore50" } } } |
A continuación, añada un archivo nlog.config a su proyecto con el siguiente contenido:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
<?xml versión="1.0" codificación="utf-8" ?> <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" autoReload="true" internalLogLevel="Depurar" internalLogFile="c:\temp\internal-nlog.txt"> <targets> <objetivo xsi:tipo="Archivo" nombre="allfile" fileName="c:\temp\nlog-all-${shortdate}.log" diseño="${longdate}|${event-properties:item=EventId.Id}|${logger}|${uppercase:${level}}|${message} ${exception}" /> <objetivo xsi:tipo="Nulo" nombre="agujero negro" /> </targets> <rules> <!--All logs, including from Microsoft--> <logger nombre="*" nivel mínimo="Rastro" writeTo="allfile" /> </rules> </nlog> |
Por último, añade el código para configurar el SDK de Couchbase para el registro:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
utilizando Couchbase; utilizando Couchbase.Registro; utilizando Microsoft.Extensiones.Registro; utilizando NLog.Extensiones.Registro; espacio de nombres ConsolaApp2 { público clase Programa { público estático void Principal(cadena[] args) { var fábrica = nuevo LoggerFactory(); fábrica.AddDebug(); fábrica.AddNLog(); fábrica.ConfigureNLog("nlog.config"); //configurar el registro en el cliente couchbase var config = nuevo ClientConfiguration { LoggerFactory = fábrica }; var grupo = nuevo Grupo(config); //utilizar el cliente couchbase } } } |
Tenga en cuenta que el project.json tiene un copyToOutput.incluir valor para nlog.config . Esto es necesario para que la herramienta copie ese archivo en el directorio de salida cuando se construya.
Ahora, para los binarios de .NET 4.5 Full Framework, la dependencia de Común.Registro y cualquier configuración de registro existente debería funcionar como siempre.
Infraestructuras de datos
Las datastructures son una nueva forma de trabajar con los documentos de Couchbase como si fueran estructuras de datos habituales en Informática, como por ejemplo enumera, colas, diccionarios o establece. Hay dos implementaciones en el SDK; una como una serie de métodos en CouchbaseBucket que proporcionan funcionalidad para operaciones comunes de estructuras de datos y otra como implementaciones de las interfaces dentro de Sistema.Colecciones.Genéricos . He aquí una descripción de cada clase Datastructure que se encuentra en el SDK:
- CouchbaseDictionary<TKey, TValue> : Representa una colección de claves y valores almacenados dentro de un Documento Couchbase.
- CouchbaseList<T> : Representa una colección de objetos, almacenados en el servidor Couchbase, a los que se puede acceder individualmente mediante un índice.
- CouchbaseQueue<T> : Proporciona una estructura de datos Couchbase persistente con comportamiento FIFO.
- CouchbaseSet<T> : Proporciona un conjunto persistente de Couchbase, que es una colección de objetos sin duplicados.
Todas estas clases se encuentran en Couchbase.Colecciones espacio de nombres. He aquí un ejemplo de utilización de un CouchbaseQueue<T> :
|
1 2 3 4 5 6 7 |
var cola = nuevo CouchbaseQueue<Poco>(_bucket, "alguna llave"); cola.Poner en cola(nuevo Poco { Nombre = "pcoco1" }); cola.Poner en cola(nuevo Poco { Nombre = "pcoco2" }); cola.Poner en cola(nuevo Poco { Nombre = "pcoco3" }); var artículo = cola.Puesta en cola(); Afirme.AreEqual("pcoco1", artículo.Nombre); |
Multiplexación IO
El SDK de Couchbase ha utilizado la agrupación de conexiones en el pasado para permitir un alto rendimiento y escala a costa de la latencia y la utilización de recursos. En Couchbase 2.2.4 introdujimos un modelo de IO mejor llamado Multiplexing IO o MUX-IO, que el cliente podía configurar para usar (por defecto eran conexiones agrupadas).
En 2.4.0 estamos haciendo MUX-IO el modelo IO por defecto y haciendo connection pooling opcional. Lo que esto significa para usted es que algunas propiedades de connection pooling en su configuración pueden seguir siendo usadas SDK. Por ejemplo:
- PoolConfiguration.Tamaño máximo se sigue utilizando, pero deben ser valores relativamente pequeños - por ejemplo, 5-10
- PoolConfiguration.Tamaño mínimo debe ser 0 o 1
Para desactivar MUX-IO basta con configurar el parámetro ClientConfiguration.UseConnectionPoolinga true (el valor predeterminado es false) para utilizar la agrupación de conexiones:
|
1 2 3 4 5 6 |
var clientConfig = nuevo ClientConfiguration{ UseConnectionPooling = falso }; var grupo = nuevo Grupo(clientConfig); //abrir cubos y utilizar el cliente |
Streaming N1QL y vistas
Las vistas y N1QL de flujo continuo son una optimización del rendimiento en determinados casos en los que la cantidad de datos recuperados es grande. Para entender por qué, veamos cómo funcionan las consultas sin flujo:
- Se envía una solicitud al servidor.
- El servidor realiza el procesamiento y devuelve los resultados como un flujo después de procesar toda la respuesta.
- El cliente almacena en búfer todo el flujo y luego lo deserializa en una colección de tipo "T", donde T es la POCO a la que se asigna cada resultado.
- El servidor devuelve la lista a la aplicación dentro de su IResultado
¿Qué puede fallar? Piensa en resultados muy grandes y en que los recursos de memoria son finitos: al final siempre te encontrarás con un OutOfMemoryException ¡! También hay otros efectos secundarios relacionados con la recolección de basura.
Con los clientes de streaming el proceso es el siguiente:
- Se envía una solicitud al servidor
- El servidor realiza el procesamiento y devuelve los resultados en forma de flujo tan pronto como las cabeceras de respuesta estén disponibles.
- El cliente lee parcialmente las cabeceras y los metadatos y luego hace una pausa hasta que se produce la iteración.
- Cuando la aplicación comienza a iterar sobre el IResultado cada elemento se lee de uno en uno sin almacenarlo en una colección subyacente.
El gran beneficio aquí es que el conjunto de trabajo de la memoria no crecerá a medida que la colección crece y se redimensiona internamente por .NET. En su lugar, usted tiene un tamaño fijo de trabajo de la memoria y GC puede ocurrir tan pronto como el objeto leído se descarta.
Para utilizar el streaming N1QL y las vistas, todo lo que hay que hacer es llamar a la función UseStreaming() y pasarle true a stream:
|
1 2 3 4 5 |
var solicitar = nuevo Solicitud de consulta("SELECT * FROM `viaje-muestra` LIMIT 100;").UseStreaming(verdadero); utilizando (var resultado = _bucket.Consulta<dinámico>(solicitar)) { Consola.WriteLine(resultado); } |
Si se introduce false, se almacenará en el búfer toda la respuesta y se procesará antes de devolverla.
Cancelación de la consulta N1QL
Esta función permite cancelar consultas N1QL de larga duración antes de que se completen utilizando tokens de cancelación de tareas. Por ejemplo:
|
1 2 3 4 |
var cancellationTokenSource = nuevo CancellationTokenSource(TimeSpan.DesdeMilisegundos(5)); var resultado = await _bucket.QueryAsync<dinámico>(queryRequest, cancellationTokenSource.Ficha); //hacer algo con el resultado |
Este commit se realizó a través de una contribución comunitaria de Brant Burnett de CenteredgeSoftware.com!
Nota importante sobre TLS/SSL en Linux
Hay un problema en Linux con el que puede encontrarse si está utilizando SSL: se lanzará una PlatformNotSupportedException si tiene una versión de libcurl instalada en el servidor < 7.30.0. La solución consiste simplemente en actualizar su instalación de libcurl en Linux a una versión igual o superior a 7.30.0. Puede leer más sobre esto en el ticket de Jira: NCBC-1296.
[...] Léelo todo en la entrada del blog de Jeff Presentando Couchbase .NET 2.4.0 - .NET Core GA. [...]
[...] el reciente lanzamiento de Couchbase .NET SDK 2.4.0 ha añadido muchas nuevas características. Sin embargo, hay una característica menor que vale la pena mencionar. [...]
[Con el lanzamiento de Couchbase .NET SDK 2.4.0, Couchbase ya tiene soporte oficial para .NET Core. Esto abre un nuevo y amplio mundo para .NET [...]