Edition 0 Updated to asp. Net core 0

A Model used by MongoDB API 
First, you need to define a model that will hold the data coming from the database in your 
application’s memory space.
Here’s an example of the model used for Locations at 
eShopOnContainers. 
using
MongoDB.
Bson
; 
using
MongoDB.
Bson
.
Serialization
.
Attributes
; 
using
MongoDB.
Driver
.
GeoJsonObjectModel
; 
using
System.
Collections
.
Generic
; 
public
class
Locations 
{ 

---

264 
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns 
[BsonId] 
[
BsonRepresentation
(BsonType.
ObjectId
)] 
public
string
Id { 
get
; 
set
; } 
public
int
LocationId { 
get
; 
set
; } 
public
string
Code { 
get
; 
set
; } 
[
BsonRepresentation
(BsonType.
ObjectId
)] 
public
string
Parent_Id { 
get
; 
set
; } 
public
string
Description { 
get
; 
set
; } 
public
double
Latitude { 
get
; 
set
; } 
public
double
Longitude { 
get
; 
set
; } 
public
GeoJsonPoint Location 
{ 
get
; 
private
set
; } 
public
GeoJsonPolygon Polygon 
{ 
get
; 
private
set
; } 
public
void
SetLocation
(
double
lon, 
double
lat) => 
SetPosition
(lon, lat); 
public
void
SetArea
(List coordinatesList) 
=> 
SetPolygon
(coordinatesList); 
private
void
SetPosition
(
double
lon, 
double
lat) 
{ 
Latitude = lat; 
Longitude = lon; 
Location = 
new
GeoJsonPoint( 
new
GeoJson2DGeographicCoordinates
(lon, lat)); 
} 
private
void
SetPolygon
(List coordinatesList) 
{ 
Polygon = 
new
GeoJsonPolygon( 
new
GeoJsonPolygonCoordinates( 
new
GeoJsonLinearRingCoordinates( 
coordinatesList))); 
} 
} 
You can see there are a few attributes and types coming from the MongoDB NuGet packages. 
NoSQL databases are usually very well suited for working with non-relational hierarchical data. In this 
example, we are using MongoDB types especially made for geo-locations, like 
GeoJson2DGeographicCoordinates
. 
Retrieve the database and the collection 
In eShopOnContainers, we have created a custom database context where we implement the code to 
retrieve the database and the MongoCollections, as in the following code. 
public
class
LocationsContext 
{ 
private
readonly
IMongoDatabase _database = 
null
; 
public
LocationsContext
(IOptions settings) 
{ 
var
client = 
new
MongoClient
(settings.
Value
.
ConnectionString
); 
if
(client != 
null
) 
_database = client.
GetDatabase
(settings.
Value
.
Database
); 
} 
public
IMongoCollection Locations 
{ 

---

265 
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns 
get 
{ 
return
_database.
GetCollection
(
"Locations"
); 
} 
} 
} 
Retrieve the data 
In C# code, like Web API controllers or custom Repositories implementation, you can write similar 
code to the following when querying through the MongoDB API. Note that the 
_context
object is an 
instance of the previous 
LocationsContext
class. 
public
async Task 
GetAsync
(
int
locationId) 
{ 
var
filter = Builders.
Filter
.
Eq
(
"LocationId"
, locationId); 
return
await _context.
Locations
.
Find
(filter) 
.
FirstOrDefaultAsync
(); 
} 
Use an env-var in the docker-compose.override.yml file for the MongoDB connection 
string 
When creating a MongoClient object, it needs a fundamental parameter which is precisely the 
ConnectionString
parameter pointing to the right database. In the case of eShopOnContainers, the 
connection string can point to a local MongoDB Docker container or 
to a “production” Azure Cosmos 
DB database. That connection string comes from the environment variables defined in the 
docker-
compose.override.yml
files used when deploying with docker-compose or Visual Studio, as in the 
following yml code. 
# docker-compose.override.yml
version:
'3.4'
services:
# Other services
locations-api:
environment:
# Other settings
-
ConnectionString=${ESHOP_AZURE_COSMOSDB:
-mongodb://nosqldata}
The 
ConnectionString
environment variable is resolved this way: If the 
ESHOP_AZURE_COSMOSDB
global variable is defined in the 
.env
file with the Azure Cosmos DB connection string, it will use it to 
access the Azure Cosmos DB database in the cloud. If it’s not defined, it will take the 
mongodb://nosqldata
value and use the development MongoDB container. 
The following code shows the 
.env
file with the Azure Cosmos DB connection string global 
environment variable, as implemented in eShopOnContainers: 
# .env file, in eShopOnContainers root folder
# Other Docker environment variables
ESHOP_EXTERNAL_DNS_NAME_OR_IP=host.docker.internal 
ESHOP_PROD_EXTERNAL_DNS_NAME_OR_IP= 
#ESHOP_AZURE_COSMOSDB=

---

266 
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns 
#Other environment variables for additional Azure infrastructure assets
#ESHOP_AZURE_REDIS_BASKET_DB=
#ESHOP_AZURE_STORAGE_CATALOG_URL=
#ESHOP_AZURE_SERVICE_BUS=
Uncomment the ESHOP_AZURE_COSMOSDB line and update it with your Azure Cosmos DB 
connection string obtained from the Azure portal as explained in 
Connect a MongoDB application to 
Azure Cosmos DB
. 
If the 
ESHOP_AZURE_COSMOSDB
global variable is empty, meaning it’s commented out in the 
.env
file, 
then the container uses a default MongoDB connection string. This connection string points to the 
local MongoDB container deployed in eShopOnContainers that is named 
nosqldata
and was defined 
at the docker-compose file, as shown in the following .yml code: 
# docker-compose.yml
version:
'3.4'
services:
# ...Other services...
nosqldata:
image:
mongo