Whats the reason for IMapper still has MapsterMapper Namespace?

[DevTKSS]

Hey, I was wondering why the IMapper and ServiceMapper Definition seems to be the only one with the Namespace MapsterMapper instead of the "regular" Mapster namespace that`s used everywhere else? 😅

Fir example, quick search in src/ directory:

• https://github.com/MapsterMapper/Mapster/blob/master/src%2FMapster.DependencyInjection%2FServiceMapper.cs
• https://github.com/MapsterMapper/Mapster/blob/master/src%2FMapster%2FInterfaces%2FIMapper.cs

The interface is not equally named than the Namespace so this shouldn't be a reason in my opinion the IDE would assume we want to call a namespace as type...

Mediator.Mediator brings potentially more problems than Mapster.IMapper with this in my opinion

I would assume there will be a reason you did this, because there is the pragma disable for ReSharper to not check this for once, but I am not sure why ?

Issue search was not giving any answer to this that I would have seen, so if I missed it, feel free to tell!

[stagep]

I did a rename on the namespace and it made 12 changes. There is now ambiguity in TestAdaptHelper which requires prefixing AutoMapper to IMapper and Mapper

https://github.com/MapsterMapper/Mapster/blob/master/src/Benchmark/TestAdaptHelper.cs

private static readonly AutoMapper.IMapper _mapper = new AutoMapper.Mapper(

Once this is corrected, you can build and run all the tests. The only breaking change would be for projects that are using both Mapster and AutoMapper that they may need to further qualify IMapper and Mapper with either AutoMapper or Mapster. I can't know how big a change this is because I am only using Mapster, but for those migrating to Mapster from AutoMapper, it could be annoying. I added AutoMapper to my mapping project and it caused no issues.

[DevTKSS]

@stagep

I added AutoMapper to my mapping project and it caused no issues.

you say, you are using the namespace and alternative output of the Mapster.Tool or do you mean by this the typical Domain Project where the Dto used Types would be located in?

I am only using Mapster, but for those migrating to Mapster from AutoMapper, it could be annoying

1. Do we expect users to use both at the same time?
2. I am using global usings for everything that's needed in multiple files (which I would assume Mappers will be), so... just for the MapsterMapper Namespace, that was eitherway only required in my Project for very few (1 or 2?) definitions, I would consider this as not very strong Argument 🤔 but I am open to hear other opinion!

[DocSvartz]

@stagep @DevTKSS Were you able to get results from these benchmarks?

[DevTKSS]

I never did Benchmarks, sorry 😅 I don't think I can help you with this...

[stagep]

I did not go through the whole process of changing the namespace, building and then referencing this new version of Mapster.Tool, but I could later today.

Users migrating from AutoMapper to Mapster would likely be referencing both packages at the same time.

I also use global usings except when I have a type that is used by another library. Then I use the using at the class level and even put a comment not to add it to global usings. Here is an example from my code base

using Grpc.Core; // do not add to GlobalUsings as Grpc.Core has a class named Status

I do not think it will be an issue but I have no real data to base this upon, only my own experience.

[DevTKSS]

@stagep for those cases I am always using static using

[DocSvartz]

!Off topic

@stagep Have you checked if Mapster Tool generates Interfaces or Config where using Inherits or Include?

[DocSvartz]

I can't say for sure, but it looks more like "By Design" from the original author of Mapster.
Moreover, this organization itself is also called MapsterMapper :)

[DocSvartz]

The commits that added these files definitely belong to him.