[CSHARP-476] Support parameterized constructors on deserialization Created: 23/May/12 Updated: 20/Mar/14 Resolved: 12/Feb/13 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | None |
| Affects Version/s: | 1.4.2 |
| Fix Version/s: | 1.8 |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Pantyushin Roman | Assignee: | Robert Stam |
| Resolution: | Done | Votes: | 1 |
| Labels: | constructor, deserialization | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
I would be happy to see support for parameterized constructors during deserialization process. The target constuctor may be marked with special attribute or selected automatically. Example of this feature is in JSON.NET. |
| Comments |
| Comment by auto [ 16/Jan/13 ] | |||||||||||||||||||||||
|
Author: {u'date': u'2013-01-16T02:26:11Z', u'email': u'robert@10gen.com', u'name': u'rstam'}Message: | |||||||||||||||||||||||
| Comment by Pantyushin Roman [ 25/May/12 ] | |||||||||||||||||||||||
|
The another, more flexible way for ctor parameters mapping:
With default implementation of ICtorParameterMapConvention that checking all (even readonly) fields and properties of objectType and execute name comparison (ignore casing). Then all matching members unites with result of IMemberFinderConvention.FindMembers(Type) and used for (de)serialization. | |||||||||||||||||||||||
| Comment by Pantyushin Roman [ 24/May/12 ] | |||||||||||||||||||||||
|
I think in most simple case constructor for deserialization should be determined "statically" (i.e. it should not depend on existing document fields). It will be something like this:
(2) There should be new convention for cases when ctor does not specified directly (as described in (1)). This convention should activate process of automatic selection of ctor (to not break existing code). Something like:
When it's activated, ctor automatically selected using following steps:
and default implementation
There may be new method in class map (and new attribute) to directly map ctor parameter to property, for special cases:
Before (de)serialization we go through all public properties without setter and filter the ones that matches ctor parameter name. This properties concatenated with result of IMemberFinderConvention.FindMembers(Type) and then used on (de)serialization process. This logic can be avoided by providing new implemenation of IMemberFinderConvention that returns public properties without setter, but in this case we will be forced to manually unmap all calculated properties like this:
Then we map all ctor parameters to properties. Exception should be thrown if not all ctor parameters has mapped property. Of course all "Bson" attributes applied to properties are used on deserialization of mapped ctor parameters. | |||||||||||||||||||||||
| Comment by Craig Wilson [ 24/May/12 ] | |||||||||||||||||||||||
|
Ok. Do you have any proposals you'd like us to consider regarding how to do this? We have some ideas internally but would like to hear yours as well. The issue we'll need to figure out is how to match up the member for the class with the parameter from the constructor. Remember that there are conventions that will need to be created/altered to ensure consistency between the two. | |||||||||||||||||||||||
| Comment by Pantyushin Roman [ 24/May/12 ] | |||||||||||||||||||||||
|
Yes. The example:
I want constructor "Class1(string)" to be called during deserialization, with provided deserialized "name" value. This allows me to have object always in correct state. | |||||||||||||||||||||||
| Comment by Craig Wilson [ 23/May/12 ] | |||||||||||||||||||||||
|
For the next release, we have added support for setting a constructor using a delegate.
However, I assume that you are asking for MongoDB fields to get deserialized and set through the constructor. Is that correct? |