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.

[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]

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

I will put this on my list for this weekend and let you know my results, or should I say the benchmarks :)

[DocSvartz]

I couldn't get them to run. 😔
I just wanted to know if you ran it and it worked, or if you couldn't fix it.

[DocSvartz]

@stagep @DevTKSS I couldn't fix the original benchmark.😔
But I created a simplified version based on it so I could compare different Mapster releases.
Currently, it's only for NuGet packets.

[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?

[stagep]

!Off topic

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

Can you enhance the question with some simple code so that I understand the question fully, and can answer the question correctly?

[DocSvartz]

Interfaces :
or one of destination member declaration as Interface

public void Register(TypeAdapterConfig config)
{
    config.NewConfig<FooDto, IFoo>();
       
}

public class UserAccount
 {
     
     public string Id { get; set; }
     public string? Email { get; set; }
     public DateTime Created { get; set; }
     public DateTime? Modified { get; set; }
     public IEmployeeName Name { get; set;}
 }

public interface IEmployeeName 
{
    public string Name { get; set; }
}

[DocSvartz]

Inherits:

TypeAdapterConfig<Vehicle, VehicleDto>.NewConfig()
    .Include<Car, CarDto>();

Vehicle vehicle = new Car { Id = 1, Name = "Car", Make = "Toyota" };

var dto = vehicle.Adapt<Vehicle, VehicleDto>();

Include is copying the settings. I think it should actually work.

If Mapster Tool is a generate Dto and mapper to Dto, then this is not really necessary.

[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.

[stagep]

Whatever the original intent of the MapsterMapper namespace, it is an internal namespace and lets go with the "if it's not broken, then why fix it" approach. If we are in agreement then we should close this discussion.