Support accepting destination type as a parameter
See original GitHub issueExample:
public partial class Mapper
{
public partial Car MapToModel(CarDto dto);
public partial CarDto MapToDto(Car model);
public partial Dog MapToModel(DogDto dto);
public partial DogDto MapToDto(Dog model);
public partial TDestination Map<TSource, TDestination>(TSource source);
public partial TDestination Map<TDestination>(object source, Type sourceType);
public partial TDestination Map<TDestination>(object source);
public partial object Map(object source, Type destinationType);
public partial object Map(object source, Type sourceType, Type destinationType);
public partial object Map(object source, object destination, Type sourceType, Type destinationType);
}
public class Car
{
public required string Name { get; set; }
}
public class Dog
{
public required int LegsCount { get; set; }
}
public record CarDto(string Name);
public record DogDto(int LegsCount);
Will be generated to this code, using all known mappings in the current class:
public partial class Mapper
{
public partial object Map(object source, Type destinationType)
{
if (destinationType.IsAssignableFrom(typeof(CarDto)) && source is Car car) return MapToDto(car);
if (destinationType.IsAssignableFrom(typeof(Car)) && source is CarDto carDto) return MapToModel(carDto);
if (destinationType.IsAssignableFrom(typeof(DogDto)) && source is Dog dog) return MapToDto(dog);
if (destinationType.IsAssignableFrom(typeof(Dog)) && source is DogDto dogDto) return MapToModel(dogDto);
throw new NotSupportedException();
}
}
What does this give us?
If user plans to migrate their project from Automapper to Mapperly, then user could just implement either interface IMapper
interface or IMapperBase
in their Mapperly mapper class.
This will reduce amount of refactoring required on the project. Probably, project code will not change at all, except for IServiceContrainer configuration code.
p.s. I don’t know cases when Type sourceType
is needed, but it is there in IMapperBase
interface.
Issue Analytics
- State:
- Created 5 months ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Pass data between destinations
Define destination arguments. Supported argument types; Override a destination argument in an action. Use Safe Args to pass data with type safety.
Read more >Solved: How to pass a parameter to an link to destination
So Im using the "link to destination" event handler and selecting type "external URL". However, I need to pass a parameter into this...
Read more >Typescript multiple type parameter
To access the variable that is only available on a given Type, you need to use a type ... isEqualTo(destination.x, destination.y)) { ....
Read more >API destinations
A connection specifies the authorization type and parameters to use to authorize with the API destination endpoint. You can choose an existing connection ......
Read more >Support for type hints — Python 3.11.4 documentation
Subtypes are accepted as arguments. New features are frequently added to the typing module. The typing_extensions package provides backports of these new ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@tvardero for now only
object Map(object source, Type targetType);
is supported. Most other AutoMapperIMapper
methods should be implementable by using theobject Map(object source, Type targetType);
method. What I think could be a nice addition to Mapperly is to also supportvoid Map(object source, object target)
andvoid Map(object source, object target, Type targetType)
. These would probably also contribute to support AutoMapper migrations.A model with a property
Type TargetType
seems to be an edge case which should be addressed in a concept on how to implement #103. A solution could be to use attributes to mark the additional parameters or the the target type (which then would be a breaking change).Also second question, if in the future passed parameters will be supported (#103), what will happen if target model has its own property
Type TargetType
. How the conflict will be resolved, or what user should do in such cases?