Couchbase .NET SDK 2.0 Developer Preview 3

Como continuación de la anterior DP2 en junio, estamos lanzando otra vista previa para desarrolladores, DP3. Esta vista previa para desarrolladores, añade una plétora de correcciones de errores, características y lo más importante, los cambios en la API pública a través de a) proporcionar métodos para trabajar con "documentos" y b) cambiar la forma en que un objeto de clúster es instanciado. También hemos trasladado el repositorio de CouchbaseLabs a Couchbase en Github; hablaré de ello más adelante.

Documentos, documentos por todas partes

Uno de los principales cambios en esta versión preliminar para desarrolladores y una desviación del SDK .NET anterior, es la evolución de Couchbase de un almacén de Claves/Valores a una base de datos de documentos - que a su vez se refleja en la API pública. Esto significa que ahora tenemos métodos que toman y devuelven un objeto documento en lugar de un par K/V. Todas las otras bondades de Couchbase como CAS y restricciones de durabilidad y otras características se siguen proporcionando, pero ahora las envolvemos en un único objeto "documento", del que mediante la configuración de las distintas propiedades, se obtiene el comportamiento que se desea.

Para soportar el concepto de "documento", se han añadido a la interfaz de IBucket una serie de métodos basados en documentos que soportan una nueva clase Document:

El resultado de una llamada utilizando uno de estos nuevos métodos de documento es un objeto DocumentResult, que es similar a los objetos OperationResult que son devueltos por los otros métodos K/V. La diferencia es que el campo Document es una referencia a Document. La diferencia es que el campo Documento es una referencia a Documento. Si desea obtener directamente el valor del documento (el valor de T), utilice el campo Valor.

Por ejemplo, así es como ahora (usando DP3) almacenarías un documento JSON en Couchbase usando el método Upsert:

Si te lo estás preguntando, Upsert() es un método que inserta o actualiza un documento dependiendo de si existe o no. Otros métodos basados en documentos son:

• Insert(): inserta un documento, a falta de que exista.
• Replace(): reemplaza un documento existente, fallando si no existe.
• Remove(): elimina un documento si existe.
• GetDocument(): devuelve un documento para un id dado.

¿Significa esto que Couchbase ya no soporta las operaciones tradicionales de Memcached basadas en K/V? Por supuesto que no. La API seguirá soportando estas operaciones, sin embargo, la esperanza es que el nuevo enfoque basado en "documentos" hará más fácil para los desarrolladores utilizar la API y Couchbase en general para una gama más amplia de aplicaciones. Al menos debería hacer que la semántica de trabajar con documentos JSON sea más fácil de entender e intuitiva.

¿Singleton's? ¡No necesitamos a ningún apestoso Singleton!

En DP1 y DP2 para instanciar un objeto CouchbaseCluster, ya que era un Singleton cargado perezosamente, primero creabas un ClientConfiguration y lo pasabas al método estático Initialize() y luego llamabas a Get() en la clase CouchbaseCluster para obtener una referencia al objeto cluster. Aunque la intención era buena (asegurar que el CouchbaseCluster es un objeto global), las desventajas hacían que no fuera una elección de diseño estelar: significaba que podías tener uno y sólo un objeto CouchbaseCluster por AppDomain (¿y si tenías dos clusters de Couchbase separados que estabas usando en una sola app?) y era una forma un poco rara de empezar a usar un bucket - una experiencia de programación incómoda.

En DP3 decidimos eliminar el requisito explícito de un Singleton y en su lugar dividir la clase en una clase estándar CouchbaseCluster, sin límites en el número que podría ser instanciado y una clase ClusterHelper que es un singleton envoltorio alrededor de CouchbaseCluster en el caso de que quisieras estar seguro de que sólo una instancia sería creada. Lo mejor de ambos mundos.

A continuación se muestra un ejemplo de creación de un objeto CouchbaseCluster en DP3:

Aquí hay un ejemplo de uso de la clase ClusterHelper para asegurar que sólo un único objeto CouchbaseCluster sería creado por AppDomain:

¿Te estás preguntando por qué incluimos un objeto ClusterHelper? Es porque el objeto CouchbaseCluster es un objeto muy caro de crear y funciona mejor cuando se crea cuando la aplicación se inicia y se destruye cuando la aplicación termina. Tendré más sobre esto en un futuro post.

Pruébelo (y envíenos sus comentarios).

Descarga los binarios a continuación o consulta el código fuente en Github y dinos lo que piensas. Además, no olvides que esto es un pre-lanzamiento y las cosas cambiarán definitivamente antes de Beta y GA. La mayoría de los cambios serán internos, especialmente alrededor de las porciones de IO y namespaces. Dependiendo de la retroalimentación de la comunidad las interfaces públicas pueden cambiar también.

Por favor, por favor, no utilice esto en la producción Además, aunque la funcionalidad básica funciona, el código aún no ha superado un conjunto exhaustivo de pruebas situacionales, por lo que las cosas pueden fallar durante un escenario de Failover/Swap/Rebalance.

Fuente y binarios

• Tenga en cuenta que la rama de desarrollo del SDK 2.0 es ahora la rama maestro en Github y la rama de desarrollo 1.X se llama ahora liberación13.
• Si encuentras un error, crea un pull request y/o y NCBC.
• Los binarios se encuentran en aquí.