Support defining the serializer and BSON representation for a property

<small>Issue converted to Proposal by @Turnerj 2023-06-04</small>

Proposal

Allow finer control of the serialization system for MongoDB through MongoFramework. Currently you can not control the BSON Representation (eg. C# string can’t be represented as BSON ObjectId) however doing so allows greater compatibility in a number of scenarios.

This could be accomplished well with support for defining the serializer per-property in MongoFramework. With the appropriate extension methods during the builder process, you could then control the representation that would be used. This first-party support would then unlock the ability to do the same attribute-level control of serializer (and optionally representation).

Original Issue

It does not allow me to read the entities of a mongo database due to this problem.

[CristianBonilla]

It would be nice to support it in a future version or find a way to support it in older versions too.

[Turnerj]

Yes, mostly. Like I think being able to define what a particular property should be represented as is quite useful but I need to look at the bigger picture of how I’d integrate it with MongoFramework.

Right now the very high level design I’m thinking is with MongoFramework’s internal mapping system, track the serializer used for a particular property - basically allow you to set IBsonSerializer. From there, I could just add some extension methods to my builder system to allow reconfiguring an existing serializer to change representation.

The big bit with this piece of work is that it makes MongoFramework responsible about what serializer is used for what property. By that I mean, MongoFramework will be determining the default serializer for each type rather than the driver by default. This is probably a good thing to do long term anyway (gives more flexibility in mapping) but given the wide variety of types that people could use, it becomes complicated ensuring backwards compatibility.

The end result then for consumers of MongoFramework would be both a similar attribute like the driver has to define the representation and also have first-party support in the fluent builder system.