{"id":117,"date":"2014-12-16T19:35:14","date_gmt":"2014-12-16T19:35:13","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/introducing-couchbase-net-sdk-20-development-blog-series\/"},"modified":"2014-12-16T19:35:14","modified_gmt":"2014-12-16T19:35:13","slug":"introducing-couchbase-net-sdk-20-development-blog-series","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/introducing-couchbase-net-sdk-20-development-blog-series\/","title":{"rendered":"Introducing the Couchbase DOTNET SDK 2.0 Development Blog Series"},"content":{"rendered":"

Hello folks, over the next couple of months we\u2019ll be doing a series of blogs that will follow the development of the Couchbase .NET 2.0 SDK. In this post I will go over the high level architecture, some motivation and features you should expect, and what the overall goals are of the .NET SDK with respect to the other Couchbase clients: Node, PHP, Java, and C. Discussing the goals of the .NET SDK within the scope of the entire suite of Couchbase clients is an important step in unifying the API\u2019s, so that developers have a consistent programming experience no matter which SDK they chose.<\/p>\n\n\n\n

History and Motivation<\/h1>\n\n\n\n

First up, let\u2019s talk about what are motivation is for re-writing the Couchbase .NET SDK. Note that for the most part, this is a complete rewrite from scratch\u2026pretty much every component is being redesigned and redeveloped to better suit the needs of our customer and the user community at large. By now, most of us \u00a0have been warned that the single worst strategic mistake a software company can do, is rewrite working, functional code from scratch<\/a><\/em>, <\/strong>but we here at Couchbase feel it\u2019s the best decision given the history and state of the .NET 1.X SDK and the direction we want to go with the client.<\/p>\n\n\n\n

A little history might be in order here. The current client is based off of the original Memcached .NET client: Enyim.Caching<\/a>. It was written several years back and originally supported the Memcached Text protocol and eventually the Memcached Binary Protocol as well. In itself, it was designed to be a stand-alone API, not framework for creating other API\u2019s. That being said, the current .NET Couchbase Client was built on top of a fork of the Enyim.Caching source; we forked because the original author, while a great supporter, no longer had the time needed to keep the project going. The Couchbase client added view support and other Couchbase Server specific features on top of the K\/V stuff already supported by Enyim.Caching.<\/p>\n\n\n\n

Since the client was originally based off a K\/V based protocol, fitting in some of the Couchbase features has made for a bit of a thorny API. Furthermore, as more layers have been added the complexity has increased as well making supporting and maintaining the client more and more difficult. Additionally, since the client is really based off of .NET 3.5 (while we do build for 4.0, 3.5 is the LCD), we weren\u2019t progressing with the current state-of-the-art .NET features like the powerful new Task (async\/await) based asynchronous libraries\/features and improvements to the networking API\u2019s. Maintaining backwards compatibility and progressing the client is therefore impossible; we need to take a whole new direction.<\/p>\n\n\n\n

Goals and Features<\/h1>\n\n\n\n

The goals\/objectives of the Couchbase .NET 2.0 SDK are fairly simple:<\/p>\n\n\n\n