Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding a new BSON serialization provider to be able to determine that… #219

Closed
wants to merge 2 commits into from
Closed

Conversation

mfidemraizer
Copy link

Because some requirements in my project, I had to create a base class derived by some domain objects which implement IDictionary<TKey, TValue>, but these domain objects are still POCOs and I want them to be serialized using regular BSON class map serializer.

When I ran some test I found some issue: my domain object wasn't getting an auto-assigned GUID. After clonning the driver source code, I debugged the code step by step and I found that my domain objects were serialized as collections rather than POCOs, because they inherit a base class which implements IDictionary<TKey, TValue> as I mentioned above.

Then, I thought, what about a way to configure that certain types must be serialized as class maps to solve my issue?, and I implemented a serialization provider ForceAsBsonClassMapSerializationProvider to fix my problem.

For example, this new provider may be used as follows:

public class SomeImpl : IDictionary<string, object> 
{
    // Imagine that I've implemented all IDictionary<string, object> members
}

BsonSerializer.RegisterSerializationProvider(new ForceAsBsonClassMapSerializationProvider(typeof(IDictionary<string, object>)));

It can be also registered a concrete type to be forced as a BSON class map:

BsonSerializer.RegisterSerializationProvider(new ForceAsBsonClassMapSerializationProvider(typeof(SomeImpl)));

Or also both:

// Order doesn't matter...
BsonSerializer.RegisterSerializationProvider(new ForceAsBsonClassMapSerializationProvider(typeof(IDictionary<string, object>), typeof(SomeImpl)));

Because I feel that other developers might encounter the same limitation, I believe that it would be a good point merging this simple serialization provider.

Thank you in advance and I'll look forward for your comments, suggestions...!

… some types must be forced to be treated as BSON class maps. For example, an entity might implement a collection interface, but in some cases it's required to be serialized as a regular POCO class.
@rstam
Copy link
Contributor

rstam commented Oct 15, 2015

This is an interesting approach and the code looks OK to me.

We're not sure at this point whether this is something that should be in the official driver or not. This might be the kind of thing that makes more sense to have in your application.

…d, if the class implements IDictionary<TKey, TValue>, any key within the dictionary implementation which isn't a BSON element (i.e. a regular class property), it will also be serialized/deserialized like a regular property.
@mfidemraizer
Copy link
Author

@rstam Hey, thank you for your comments.

BTW, now I'm going to drop this pull request and add a new one which also includes another feature, and I believe that it will add more value to the current one, and if you want, we can continue this discussion in the new pull request.

@mfidemraizer
Copy link
Author

@rstam See #220 . If you want, you can copy-paste your comment, and we can continue the discussion there 👍

@mfidemraizer
Copy link
Author

@rstam Hey, please review #221 . I'm sorry but I had to close the other pull request because I was contributing in the wrong way. Now I've forked and created a feature branch to keep things simpler and be able to contribute more in the future. You'll also note that #221 provides an additional feature compared to #219.

Thanks in advance and I'll look forward for your comments there...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants