Inherit Microsoft.Azure.Documents.Resource? No

We can be short, just don’t. If you do, your library gets bloated and you need to add references to documentdb to ‘cross-reffed’ libraries as well, because of the ‘Resource’ dependency.

Use a POC based ‘base object’? Yes

If you implement DocumentDB for the first time, you’ll quickly find that documentation and old samples, suggest you, to use the Build in Microsoft.Azure.Documents.Resource base object properties, that DocumentDB supports.

It’s quite simple, don’t use them. There is an improved syntax, like using mongodb, which enables you to define your own id and such.

say, this one

public class BaseObject
    {
        public BaseObject()
        {
            UpdateTimeStamp();
        }
             public void UpdateTimeStamp()
        {
            this.timestamp = DateTime.UtcNow;

        }
 
        [ModelIgnore]
        public virtual int? document_type { get; set; }

        [JsonProperty("id", Required = Required.DisallowNull)]
           public Guid id { get; set; }


        [JsonProperty("timestamp", Required = Required.DisallowNull)]
        public DateTime timestamp { get;  set; }
        /// <summary>
        /// warning, do not SET this is a calculated field
        /// </summary>
        [JsonProperty("name", Required = Required.DisallowNull)]
        public string name { get; set; }

}

 

Now, your DocumentDB Context class (or whatever you named it) could have a method like this

 

public async Task<bool> DeleteItemsAsync(BaseObject item)
        {
                      var collection = MetaUtil.CollectionId(item.GetType());
            
            //calculate the URL ourselves
            // this differs from SelfLink but seems to work!
          
var docuId = UriFactory.CreateDocumentUri(DatabaseId, collection, item.id.ToString());
            try
            {
     
                var response = await _client.DeleteDocumentAsync(docuId);

                   return response.StatusCode == HttpStatusCode.NoContent;
            }
            catch (Exception ex)
            {
                Trace.TraceError("DeleteItem failed {0}", ex);
                return false;
            }
        }

 

 

As you can use, there is a UriFactory class, that contains a lot of static uri creators, for any object type, that DocumentDB supports.

B.t.w. I like DocumentDB. After finding out about https://azure.microsoft.com/en-us/blog/azure-documentdb-bids-fond-farewell-to-self-links/, I quickly could ‘unbloat’ the library :)