Skip to content

Flow resolution context to nested mappings - #2940

Merged
jbogard merged 3 commits into
masterfrom
flow-mapper-and-context
Jan 9, 2019
Merged

Flow resolution context to nested mappings#2940
jbogard merged 3 commits into
masterfrom
flow-mapper-and-context

Conversation

@jbogard

Copy link
Copy Markdown
Contributor

Fixes#2937

=> _inner.Map(source, default(TDestination), _resolutionContext);

public TDestination Map<TSource, TDestination>(TSource source, Action<IMappingOperationOptions<TSource, TDestination>> opts)
{

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is some replication. It could be avoided by having the called Map methods always receive an optional context parameter.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want to add any more optional parameters to the public API, if i can avoid it. Those have backwards compat problems.

The biggest problems were the overloads taking Action<IMappingOperationOptions>. Those really shouldn't be allowed inside an IRuntimeMapper.

One option would be to separate the interface/objects for IMapper and IRuntimeMapper. Only put the things you should be able to do from the outermost mapping API on IMapper, and only the things you can do during a runtime mapping on IRuntimeMapper.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense. It's weird right now.

Comment threadsrc/AutoMapper/ResolutionContext.cs Outdated
{
Options = options;
Mapper = mapper;
Mapper = new RuntimeMapper(this, mapper);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's an extra allocation for every Map call with context. It could be avoided by having the context privately implement IMapper and return this from the Mapper property. But I see why you might not want to do that :)

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha! I've already introduced a separate object - I'm not sure it's a terrible idea. I'll push a commit to see what it looks like.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK just pushed this. I think it works better - and in the future, we may want to remove the implicit interface implementation and the Mapper property, and clean up the interface to only the things that make sense for doing mappings inside a Map context.

Also we may have to rename this object. ResolutionContext is....a weird name.

@lbargaoanu

Copy link
Copy Markdown
Contributor

A minor version bump?

@jbogard
jbogard merged commit 36b2be2 into masterJan 9, 2019
@jbogard
jbogard deleted the flow-mapper-and-context branch January 9, 2019 15:07
@jbogardjbogard added this to the v.next milestone Jan 9, 2019
@lock

lockBot commented May 5, 2019

Copy link
Copy Markdown

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@locklockBot locked as resolved and limited conversation to collaborators May 5, 2019
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ResolutionContext lost in nested mapping

2 participants

@jbogard@lbargaoanu