Story Details for articles
1 - DocumentDB - Golf Tracker Article - Overview
A Real-World App with Azure DocumentDB
In this series I will be demonstrating some best practices and concepts to make your DocumentDB application go smoother and develop faster.
Single Collection Concept (SCC)
This is a term I'm coining for the technique I'm using for storing documents of different shapes into the same DocumentDB collection for easy management. The technique to execute this is not all that earth-shattering, but it hasn't been demonstrated in any application I've seen for DocumentDB.
Andrew Liu describes this technique, plus many other things in this blog post.
So since there wasn't any sample available, I decided to build one, since I have to use this concept on an upcoming project. This was to be a proof-of-concept exercise that would end up having many other techniques and processes incorporated to make it a more real-world application instead of a simple, and most of the time useless, "Hello World" application.
The requirement is simple, store documents of different shapes in the same collection and be able to manage them as you would normally, without regard for taking this anomaly into account during day-to-day operations.
This is a list of some of the technologies and techniques used in this application:
- WebApi 2 - a stand-alone project that uses DocumentDB for the data store
- Azure DocumentDB - the data store
- AngularJS - a stand-alone web application
- Identity Authentication - using DocumentDB.AspNet.Identity
- Two-step Authentication - email verification on register
- CORS - to manage requests across different domains
AngularJS Web Application
This application simply allows golfers to save their golf scores. In order to do that there has to be a list of golf clubs with golf courses in the database for the golfer to choose from and post their score to.
So in this application there are two distinct types of documents:
- Golfer - this document contains all data for a golfer and their rounds of golf
- Golf Club - this document contains all data for a golf club, including golf courses and tees
This is what the page to Manage Golf Clubs looks like:
You'll notice there's a way to manage every aspect of the data for this golf club. This is the way it would usually work for applications built with a relational backend, and there should not be a difference with NoSql.
All of the data shown here is embedded in the parent document for the golf club. This means there are no table joins prior to querying the data from the server. And since it's JSON data, it's easy to manage and light weight.
Here's a look at the JSON document for golf clubs:
And this is a look at the golfer JSON document:
You'll notice that they both have very different shapes, but they are both stored in the same collection. This is accomplished by including a "type" property to the model that produces the JSON document.
You can see here on line 26 of the golfer document that I've created a "type" property with the label of the type that it is. For the golf club document, the type property is on line 41. It's simply by adding this property to each document, that I can easily manage collections of golf clubs, or collections of golfers.
In another article, I explain how this is implemented in the RepositoryBase class.
Granular Data Management
What I wanted to achieve with this application, was to figure out if I can build an application, where on the surface you can't tell what type of back end is being used. And being fairly new to NoSql I wasn't sure if it was possible, or if I could figure out how to do this.
But I wanted to use DocumentDB in my upcoming project so I really needed to see if this was going to be a viable choice over SQL Server. After reading everything I could get my hands on for DocumentDB, and watching every video, I got the idea of what NoSql was all about and that maybe I could pull this off.
But I didn't want to just be able to save and retrieve documents, but be able to do normal CRUD operations on any level in the document. If the document contained embedded documents, or arrays of documents, I needed to be able to manipulate the smallest bit of data.
I was able to figure out how to do this and I demonstrate all my methods in the next few articles and videos, so stay tuned.