Currently, the TopicMappingService maps associated topics, and then evaluates if they’re compatible with the target type. If they’re not, the association is discarded.

Instead, it would be preferable to lookup the target Type ahead of time, using the ITypeLookupService, and only map the topic if the resulting type will be compatible. That way, unnecessary mappings aren’t performed.

This has its drawbacks. It means looking up the type in each of the several places where we call to map associations. But with the type, we can call the overload of MapAsync() that accepts a Type parameter to avoid it needing to call ITypeLookupService again. And that prevents the need to conditionally call different MapAsync() overloads, as we do today in order to support [MapAs()]. Plus, we may be able to centralize this logic via a helper method.

This makes it easier to take an eager modeling strategy when the types are unknown, having confidence that type mismatches will be filtered out with comparatively little performance overhead. By contrast, the cost of this filtering today is expensive since the entire object—and, potentially, it’s associations!—needs to be mapped, independent of whether or not it’s used.