You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're using Mapster quite to the maximum extent that is somehow possible. With reflection we dynamically generate base mappings for polymorphic DTOs. Now the issue is, that we need to generate a base implementation that uses AfterMappingAsync.
Since the extensions for that are in the very same namespace and class than the base extensions of Mapster, we have a collision and need to work with extern alias which makes using it a pain. Now we need to also use global::Mapster everywhere else.
Wouldn't it be easier to just put them into a Mapster.Async namespace? I see no benefit for identical namespaces and types other than confusion and unncessary pain to work with it.
Obviously working with Reflection is an edge case here, but still. I feel like this is not very good design. I would avoid using the same namespaces and classes at all costs as it also makes navigation in the source code a lot easier and more transparent.
The text was updated successfully, but these errors were encountered:
We're using Mapster quite to the maximum extent that is somehow possible. With reflection we dynamically generate base mappings for polymorphic DTOs. Now the issue is, that we need to generate a base implementation that uses
AfterMappingAsync
.Since the extensions for that are in the very same namespace and class than the base extensions of Mapster, we have a collision and need to work with
extern alias
which makes using it a pain. Now we need to also useglobal::Mapster
everywhere else.Wouldn't it be easier to just put them into a
Mapster.Async
namespace? I see no benefit for identical namespaces and types other than confusion and unncessary pain to work with it.Obviously working with Reflection is an edge case here, but still. I feel like this is not very good design. I would avoid using the same namespaces and classes at all costs as it also makes navigation in the source code a lot easier and more transparent.
The text was updated successfully, but these errors were encountered: