Feature: Map constructor parameters

[JeremyCaney]

Currently, the TopicMappingService exclusively maps properties, and requires an empty constructor. It would add flexibility, and especially for records, if constructor parameters could also be mapped.

Challenges

There are two primary challenges with this.

Double Mapping

If a property is mapped via the constructor, how do we prevent it from being double mapped? This is especially true with records, where the constructor parameter might be used to define a property.

Order of Operations

Currently, the object is initialized, immediately added to cache, and then mapped. This would require assembling a collection of mapped values first and assigning them in unison, instead of assigning them as they're evaluated, and only then adding the object to the cache.

Circular References

Extrapolated out, the above means that topic associations might be evaluated prior to the root object(s) being created. This will introduce problems with circular references since the original topic can't be mapped until (constructor) dependencies are mapped.

Considerations

Double Mapping

• Ignore mapping properties if they aren’t an IList and aren’t set to their default value—except that would likely introduce problems with properties initialized to a specific value.
• Require [DisableMapping] on the property itself to manually prevent this situation.
• Track mapped constructor parameters in a configuration object passed down to MapProperties(). This could even be on the TopicMappingCacheEntry. That would depend on the parameter names matching their target properties.

Circular References

The circular dependency issue could be addressed by limiting what annotations can be applied to parameters. Specifically, this could exclude:

• [Include()], so no associations are mapped,
• [MapToParent], since no parent object will be available.

[JeremyCaney]

Topic associations—including topic references and relationship collections—could both be supported so long as they don’t create a circular reference. One way to handle this would be to track the Topic.Id and Type that are being initialized, and then throw an exception if that Topic.Id and Type are requested again before the first finishes initialization.

This could even be done with the existing MappedTopicCache by adding e.g an IsInitializing property to the MappedTopicCacheEntry, and then throwing an exception TryGetValue()—and possibly AddOrGet()—attempt to retrieve a MappedTopicCacheEntry with IsInitializing set to true. This way, we don’t need to introduce a new way of tracking current mapping state.

Note: This would require careful coordination from callers to avoid inadvertently tripping this exception, but as an internal class exclusively called by TopicMappingService, that should be easy to manage.

[JeremyCaney]

Relationships introduce some challenges in terms of initializing the collection. If it’s a concrete type with an empty constructor, that’s no problem. If it’s an IList<> or IEnumerable<>, we can extract the generic parameters and use them to initialize a List<>. The latter is a bit more involved.