Support AutoMapper‘s IMapper to simplify migration

[sommmen]

Hiya,

I'm using Automapper right now and i have IMapper instances here and there.
Is there support for mapperly and an IMapper interfaces class to make migration possible?

Mapster has this feature.
https://github.com/MapsterMapper/Mapster?tab=readme-ov-file#you-can-get-imapper-instance-via-dependency-injection-so-you-do-not-have-to-change-code-when-migrating-to-mapster-from-automapper

[latonz]

This is currently not supported by Mapperly.

[sommmen]

This is currently not supported by Mapperly.

Do you reckon this is possible and something you want? I may be able to work in this. Let me know what the steps would be and if you want this. If not, this van be closed.

[latonz]

I think Mapperly currently doesn‘t support all method signatures required by AutoMapper‘s IMapper (e.g. Mapperly does not support runtime target type mappings with an existing target instance yet: #884).
IMO the steps to implement this could look like this:

• analyze which features are missing in Mapperly to support the IMapper interface and create missing issues
• Implement all these features
• Implement IMapper support (detect the interface is present and generate missing methods)

Note: even if we support all IMapper members, Mapperly will never be fully compatible with AutoMapper. But I think it is still worth it to simplify the migration from AutoMapper.

rel. #884, #397

Would be very happy to see you contributing! A good starting point is the contributors documentation. Let me know if you need any hints.

[sommmen]

I think Mapperly currently doesn‘t support all method signatures required by AutoMapper‘s IMapper (e.g. Mapperly does not support runtime target type mappings with an existing target instance yet: #884). IMO the steps to implement this could look like this:

* analyze which features are missing in Mapperly to support the IMapper interface and create missing issues

* Implement all these features

* Implement `IMapper` support (detect the interface is present and generate missing methods)

Note: even if we support all IMapper members, Mapperly will never be fully compatible with AutoMapper. But I think it is still worth it to simplify the migration from AutoMapper.

rel. #884, #397

Would be very happy to see you contributing! A good starting point is the contributors documentation. Let me know if you need any hints.

Thanks for taking the time to answer me.

I started a side project but i will tryout mapperly and in that process may allocate some hours towards this, busy days however.

analyze which features are missing in Mapperly to support the IMapper interface and create missing issues

Note: even if we support all IMapper members, Mapperly will never be fully compatible with AutoMapper. But I think it is still worth it to simplify the migration from AutoMapper.

I forgot to mention this but, but i kind of follow the school of thought that mappers should be kept simple as to not obscure implementation details when mapping. In other words i think i can make do with the current feature set and was not wanting to go for full compat or anything. Only thing i now see is automapper's support for a Profile of mappings.

I like the approach in #397 with an adapter. Perhaps we could have something like:

[MapperlyIMapper]
public class IMapper;

Which would source generate a Mapperly adapter to IMapper.
We'd have to inspect the automapper profile and translate all CreateMap<TSource, TTarget to mapperly.

At this point im not sure whether a full automapper IMapper interface with purpose of migration is the right way to go.
I guess what i really want is good abstraction so i'm not tied down to a single library.

Anyways i'll have a think on this.

[latonz]

I thought again about this and I think it is not worth it. On most code bases it should be pretty trivial to identify usages of IMapper and replace them with a proper Mapperly generated method call.