# Thoughts on the C# driver for MongoDB

DevFeed: [Thoughts on the C# driver for MongoDB](<https://devfeed.tech/articles/thoughts-on-the-c-driver-for-mongodb-33388.md>)

Original publisher: [Read original article](<https://timkellogg.me/blog/2012/02/03/thoughts-on-c-driver-for-mongodb>)

Published: 2012-02-03T00:00:00Z

Content type: opinion

Language: en

Sources: [Tim Kellogg](<https://devfeed.tech/sources/tim-kellogg.md>)

Topics: [MongoDB](<https://devfeed.tech/topics/mongodb.md>), [C#](<https://devfeed.tech/topics/csharp.md>), [SQL](<https://devfeed.tech/topics/sql.md>), [migration](<https://devfeed.tech/topics/migration.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [c-sharp](<https://devfeed.tech/tags/c-sharp.md>), [data](<https://devfeed.tech/tags/data.md>), [migration](<https://devfeed.tech/tags/migration.md>), [mongodb](<https://devfeed.tech/tags/mongodb.md>), [properties](<https://devfeed.tech/tags/properties.md>), [refactor](<https://devfeed.tech/tags/refactor.md>), [serialization](<https://devfeed.tech/tags/serialization.md>), [sql](<https://devfeed.tech/tags/sql.md>)

## AI overview

The author reviews the C# driver for MongoDB based on early experimentation. The article describes its document-to-CLR object mapping, planned LINQ support, strict property requirements, BsonIgnoreExtraElements, handling of the _id field, and concerns about public properties and refactoring-related data migrations.

## Source excerpt

I recently started a new job with a software company in Boulder. Our project this year is rewriting the existing product (not a clean rewrite, more like rewrite & evolve). One of the changes we're making is using MongoDB instead of T-SQL. Since we're going to be investing pretty heavily in Mongo we all attended the mongo conference in Boulder on Wednesday. The information was great and now I'm ready to dig into my first app. Today I played around with some test code and made some notes about features/shortcomings of the C# driver.First of all, the so-called "driver" is much full featured than a typical SQL driver. It includes features to map documents directly to CLR objects (from here on I'll just say document if I mean Mongo BSON document and object for CLR object). There's plans to support Linq directly from the driver. So right off I'm impressed with the richness of the driver. However, I noticed some shortcomings.For instance, all properties in the document must be present (and of the right type) in the object. I perceived this as a shortcoming because this is unlike regular JSON serialization where missing properties are ignored. After thinking a little further, this is probably what most C# developers would want since the behavior caters toward strongly typed languages that prefer fail-fast behavior. If you know a particular document might have extraneous properties that aren't in the object, you can use the BsonIgnoreExtraElements attribute.Thinking about this behavior, refactor renaming properties could be less trivial. You would have to run a data migration script to rename the property (mongo does have an operation for renaming fields). It would be great if the driver had a [BsonAlias("OldValue")] attribute to avoid migration scripts (maybe I'll make a pull request).Something I liked was that I could use object for the type of the _id property instead of BsonObjectId. This will keep the models less coupled to the Mongo driver API. Also, the driver already