Introduction to MongoDb with .NET part 15: object serialisation continued

Introduction

In the previous post we started looking into object serialisation in the MongoDb .NET driver. Serialisation attributes, like BsonElement help us declare the mapping between our C# objects and the corresponding documents. We can map JSON properties to C# properties, declare that a property is of a type that differs from its JSON counterpart and so on.

In this post we’ll look at some more examples of data serialisation in the MongoDb .NET driver. A good documentation is located on the MongoDb page dedicated to this topic. It goes through more advanced cases like supertypes and subtypes, custom serialisation and custom attributes.

More MongoDb serialisation options

Occasionally you may want to deviate from the standard serialisation mechanism: you can ignore certain properties or define a different property name. Serialisation attributes in MongoDb will help you a great deal here. They are similar to the DataMember, IgnoreMember etc. attributes in .NET serialisation. Examples:

Ignoring elements

To ignore a property use BsonIgnore:

public class Customer
{
	public string Name { get; set; }
	public string Address { get; set; }
	IEnumerable<string> Telephones { get; set; }
	[BsonIgnore]
	public string PublicPage { get; set; }
}

The PublicPage property will not be serialised in the BSON document.

Ignore NULL values

public class Customer
{		
	public string Name { get; set; }
	[BsonIgnoreIfNull]
	public string Address { get; set; }
}

Serialise private fields

We’ve already seen the BsonElement attribute in action. It has another purpose. By default private fields are not serialised. You can use the empty BsonElement to include it in the serialisation:

public class Customer
{		
	public string Name { get; set; }
	public string Address { get; set; }
	IEnumerable<string> Telephones { get; set; }
	[BsonElement]
	private WebPage PublicPage { get; set; }
}

Different data types

Declare how the property will be represented in BSON, i.e. under which type, using the BsonRepresentation attribute:

public class Customer
{
	[BsonRepresentation(MongoDB.Bson.BsonType.Double)]
	public decimal TotalOrders { get; set; }
}

The .NET decimal type has no equivalent in BSON, it’s treated as a string which makes sorting and comparing inefficient. It’s better to cast it to a BSON double which is close enough.

The ID field

We’ve seen before that the unique ID field is called “_id” by default and is of type ObjectId. You can declare a different ID field using the BsonId attribute:

public class Customer
{
	[BsonId]
	public int CustomerId { get; set; }
}

The ID will still be serialised as “_id” in the document but you can refer to it as “CustomerId” in the POCO.

Dates

Dates are always a different beast with all the time zones and formats. MongoDb translates all local dates to UTC automatically when a date field is serialised. However, it can create problems when the date is deserialised. You’ll by default get the UTC date whereas you may expect the local one. I think it’s always wise to work only with UTC in your domains and convert dates for views only, but you can use the BsonDateTimeOptions attribute to override the default behaviour:

public class Customer
{
	[BsonDateTimeOptions(Kind = DateTimeKind.Local)]
	public DateTime CustomerSince { get; set; }
}

This way the UTC date stored in the document will be converted to the local time zone of the computer.

In case you only want to store the “date” part of a date, i.e. without the hours:minutes:seconds bit then use the DateOnly parameter of BsonDateTimeOptions:

public class Customer
{
	[BsonDateTimeOptions(Kind = DateTimeKind.Local, DateOnly = true)]		
	public DateTime CustomerSince { get; set; }
}

There are many other serialization cases we haven’t covered here. The goal was mainly to make you aware of the basic data serialisation options. For more details you can consult the MongoDb documentation page referenced above. For more customised serialisation you can read this page.

Zipcodes collection

Let’s extend the ModelContext class with a handle on the zipcodes collection as well. The zipcodes collection is definitely simpler than that of the restaurants collection. Add the following class to the Repository folder:

using MongoDB.Bson.Serialization.Attributes;
using Newtonsoft.Json;

namespace MongoDbDotNet.Repository
{
	[BsonIgnoreExtraElements]
	public class ZipCodeDb
	{
		[BsonId]
		[BsonElement(elementName: "_id")]
		public string Id { get; set; }
		[BsonElement(elementName: "city")]
		public string City { get; set; }
		[BsonElement(elementName: "loc")]
		public double[] Coordinates { get; set; }
		[BsonElement(elementName: "pop")]
		public int Population { get; set; }
		[BsonElement(elementName: "state")]
		public string State { get; set; }

		public override string ToString()
		{
			return JsonConvert.SerializeObject(this, Formatting.Indented);
		}
	}
}

The ModelContext class can be extended with the following property:

public IMongoCollection<ZipCodeDb> ZipCodes
{
	get { return Database.GetCollection<ZipCodeDb>(ConfigurationRepository.GetConfigurationValue("ZipCodesCollectionName", "¨zipcodes")); }
}

Let’s test it from the Main method:

ZipCodeDb firstInMassachusetts = modelContext.ZipCodes.FindSync(z => z.State == "MA").FirstOrDefault();
Console.WriteLine(firstInMassachusetts);

The above example gives a preview of a different style of querying than we saw before. The previous example was based on a filter built from the static Builders class. The above example demonstrates a LINQ query. We want to find the first restaurant in Massachusetts. Here is what I got in the console window:

{
  "Id": "01001",
  "City": "AGAWAM",
  "Coordinates": [
    -72.622739,
    42.070206
  ],
  "Population": 15338,
  "State": "MA"
}

In the next post we’ll look at how to query data in the .NET driver.

You can view all posts related to data storage on this blog here.