Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapping attributes: AutoMapperHelper #925

Closed
lemestrez opened this issue Mar 10, 2016 · 15 comments
Closed

Mapping attributes: AutoMapperHelper #925

lemestrez opened this issue Mar 10, 2016 · 15 comments
Assignees
Labels
Milestone

Comments

@lemestrez
Copy link
Contributor

@lemestrez lemestrez commented Mar 10, 2016

Hi,

I see, that the AutoMapperHelper use the static AutoMapper.
I like the MappingAttributes auf AbpAutoMapper an I want to use this.
But in other cases, i need to work with an self created instance of the Mapper including the MapperConfiguration.

Is there a way that we can provide the AutoMapperHelper the self created instance?

@hikalkan

This comment has been minimized.

Copy link
Member

@hikalkan hikalkan commented Mar 10, 2016

I generally use static AutoMapper. I will check it and convert to a local instance if possible.

@hikalkan hikalkan self-assigned this Mar 10, 2016
@natiki

This comment has been minimized.

@hikalkan

This comment has been minimized.

Copy link
Member

@hikalkan hikalkan commented Mar 10, 2016

Thanks. I'll follow the guide.

@natiki

This comment has been minimized.

Copy link
Contributor

@natiki natiki commented Apr 8, 2016

Hi Halil,

I need to migrate our code in terms of AutoMapper. Was wondering if you had, had time to think about this. Currently in all our services we have a method that is automatically called as part of the service constructor to call the relevant CreateMap() calls for that service.

From a performance standpoint this was good because we only created the maps we needed for that particular call. Now that the static interface is going away where do you propose I place the MapperConfiguration viz:

var config = new MapperConfiguration(cfg => {
  cfg.CreateMap<Source, Dest>();
});

so that config is:

a) Accessible application wide (for both WebForms and MVC)
b) Will "fit in" with how ABP ends up implementing things related to AutoMapper

as ultimately I will need to call things like:

IMapper mapper = config.CreateMapper();
var source = new Source();
var dest = mapper.Map<Source, Dest>(source);

and I want easy access to config. Is the "best" solution here to register MapperConfiguration with IoC somehow in Application_Start()?

@hikalkan

This comment has been minimized.

Copy link
Member

@hikalkan hikalkan commented Apr 8, 2016

For the configuration part, you can create a singleton class and inject it anywhere you need. You can create configuration on PostInitialize.

For creating mapping, I'm not sure your approach is performant. Because, you are creating the same mapping over and over again in every service call. Why don't you call this CreateMap method in static constructor of your service? Thus, it will run only once.

ABP has no much automapper stuff. It has just helper attributes and MapTo extension method as you know. MapTo is static, by it's nature and can not be used with the new "non static mapper" approach.

@natiki

This comment has been minimized.

Copy link
Contributor

@natiki natiki commented Apr 8, 2016

Hi,

Any chance I can trouble you for some code to set up the IoC singleton? As we had a "memory leak" because we were not using ResolveAsDisposable() for some instantiations I am just being cautious.

So if ABP cannot work with the "new non static Automapper" are you looking to choose a new mapper framework? Because I am seriously looking at using the ABP functionality as it makes the code cleaner etc.

@natiki

This comment has been minimized.

Copy link
Contributor

@natiki natiki commented Apr 13, 2016

@hikalkan

ABP has no much automapper stuff. It has just helper attributes and MapTo extension method as you
know. MapTo is static, by it's nature and can not be used with the new "non static mapper" approach.

Does this mean you will still keep the ABP functionality but be "forced" to use something other than AutoMapper?

@wocar

This comment has been minimized.

Copy link
Contributor

@wocar wocar commented Apr 13, 2016

I've been using Mapster and I'm happy with it. It is faster and easier. You
might want to check it out.
El El mar, 12 de abril de 2016 a la(s) 10:02 p.m., Donovan Edye <
notifications@github.com> escribió:

@hikalkan https://github.com/hikalkan

ABP has no much automapper stuff. It has just helper attributes and MapTo
extension method as you

know. MapTo is static, by it's nature and can not be used with the new
"non static mapper" approach.

Does this mean you will still keep the ABP functionality but be "forced"
to use something other than AutoMapper?


You are receiving this because you are subscribed to this thread.

Reply to this email directly or view it on GitHub
#925 (comment)

@hikalkan

This comment has been minimized.

Copy link
Member

@hikalkan hikalkan commented Apr 13, 2016

Hi,

ABP does not force any mapping library. You can use anyone you want. We have just a simple helper library (Abp.AutoMapper) to make easier to work with AutoMapper.

if ABP cannot work with the "new non static Automapper"

ABP can work with any style, no problem. But we may need to remove .MapTo extension method since it's static. I haven't worked on it yet.

@natiki

This comment has been minimized.

Copy link
Contributor

@natiki natiki commented Apr 13, 2016

Hi Halil,

But we may need to remove .MapTo extension method

Yeah, that is my concern ;-) I like that method and plan to use it extensively..... That's why am asking. Hopefully you could keep it but but with a different mapper used under the skin. That is why I am asking. :-)

@hikalkan

This comment has been minimized.

Copy link
Member

@hikalkan hikalkan commented Apr 13, 2016

Yes, I like it too and want to keep. If we use it, we should use automapper 'static-like'.
MapTo method is very simple and can be easily created for another library.

@natiki

This comment has been minimized.

Copy link
Contributor

@natiki natiki commented Apr 13, 2016

Thanks. That works for me. I am not sure I know where AutoMapper is headed with the new non static approach or that I fully agree with it, but that is what we have for now ;-)

@natiki

This comment has been minimized.

Copy link
Contributor

@natiki natiki commented Apr 21, 2016

Hi Halil,

Any chance I can get your response to my comment that starts with "Any chance I can trouble you for some code to set up the IoC singleton? As we had a "memory leak...."?

@hikalkan

This comment has been minimized.

Copy link
Member

@hikalkan hikalkan commented Apr 21, 2016

Hi @natiki
Do you want a sample code to register a class singleton? Why not just implement ISingletonDependency interface as described in documents.

@hikalkan

This comment has been minimized.

Copy link
Member

@hikalkan hikalkan commented Aug 17, 2016

Closing this issue.
see #1166 (comment)

We will continue to use Mapper.Instance (singleton instance) for .MapTo extension method. But we prefer to use IObjectMapper wherever possible.

@hikalkan hikalkan closed this Aug 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.