{"action":"created","issue":{"url":"https://api.github.com/repos/AutoMapper/AutoMapper/issues/1249","repository_url":"https://api.github.com/repos/AutoMapper/AutoMapper","labels_url":"https://api.github.com/repos/AutoMapper/AutoMapper/issues/1249/labels{/name}","comments_url":"https://api.github.com/repos/AutoMapper/AutoMapper/issues/1249/comments","events_url":"https://api.github.com/repos/AutoMapper/AutoMapper/issues/1249/events","html_url":"https://github.com/AutoMapper/AutoMapper/issues/1249","id":151276779,"number":1249,"title":"IObjectMapper refactoring","user":{"login":"jbogard","id":104498,"avatar_url":"https://avatars.githubusercontent.com/u/104498?v=3","gravatar_id":"","url":"https://api.github.com/users/jbogard","html_url":"https://github.com/jbogard","followers_url":"https://api.github.com/users/jbogard/followers","following_url":"https://api.github.com/users/jbogard/following{/other_user}","gists_url":"https://api.github.com/users/jbogard/gists{/gist_id}","starred_url":"https://api.github.com/users/jbogard/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jbogard/subscriptions","organizations_url":"https://api.github.com/users/jbogard/orgs","repos_url":"https://api.github.com/users/jbogard/repos","events_url":"https://api.github.com/users/jbogard/events{/privacy}","received_events_url":"https://api.github.com/users/jbogard/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-04-27T01:30:10Z","updated_at":"2016-04-27T01:52:52Z","closed_at":null,"body":"The `IObjectMapper` interface as it now stands is a bit limiting. At this point, `ITypeConverter` is more convenient for many scenarios as it is now fully generic and supports open generics with multiple parameters. Type converters aren't a great replacement for object mappers though as you can't really override a type map with totally different behavior, nor is there any precendence as there is with object mappers.\r\n\r\nThe other annoying thing about object mappers is there are some that can be classified as an inline mapping operation, like the string mapper. These are ones that can be most easily represented as an expression and doesn't need the full rigamoral of a new resolution context.\r\n\r\nSo I'm proposing two interfaces, one is a generic IObjectMapper, where the more complicated object mappers stay as is but can be an open generic type that gets closed. Like `ArrayMapper` gets converted to a generic one of `ArrayMapper<TSource[], TDestination[]>`. Then the string mapper wouldn't be generic since we'd be working with type objects inside the type map plan builder, and just builds an `Expression` based on the source, destination and context params passed in. Not even a lambda since it gets inlined.\r\n\r\nI haven't fully thought this through but if these concepts are added it should be easy to convert he existing ones.\r\n\r\nThe precedence would be: TypeMap, INewFangledObjectMapper, IObjectMapper.\r\n\r\nUnknown is how the inline expression mappers would overlap with the ones in LINQ or being accessed outside of the expression building spots in the type map expression builder.\r\n\r\nAnyway, some initial thoughts @TylerCarlson1 @lbargaoanu "},"comment":{"url":"https://api.github.com/repos/AutoMapper/AutoMapper/issues/comments/214942247","html_url":"https://github.com/AutoMapper/AutoMapper/issues/1249#issuecomment-214942247","issue_url":"https://api.github.com/repos/AutoMapper/AutoMapper/issues/1249","id":214942247,"user":{"login":"TylerCarlson1","id":6801536,"avatar_url":"https://avatars.githubusercontent.com/u/6801536?v=3","gravatar_id":"","url":"https://api.github.com/users/TylerCarlson1","html_url":"https://github.com/TylerCarlson1","followers_url":"https://api.github.com/users/TylerCarlson1/followers","following_url":"https://api.github.com/users/TylerCarlson1/following{/other_user}","gists_url":"https://api.github.com/users/TylerCarlson1/gists{/gist_id}","starred_url":"https://api.github.com/users/TylerCarlson1/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/TylerCarlson1/subscriptions","organizations_url":"https://api.github.com/users/TylerCarlson1/orgs","repos_url":"https://api.github.com/users/TylerCarlson1/repos","events_url":"https://api.github.com/users/TylerCarlson1/events{/privacy}","received_events_url":"https://api.github.com/users/TylerCarlson1/received_events","type":"User","site_admin":false},"created_at":"2016-04-27T01:52:52Z","updated_at":"2016-04-27T01:52:52Z","body":"I think you could build every expression with INewFangledObjectMapper, you just would have to pass in quite a few expressions to do so.  You need the source expression, destination expression, and resolution context expression.  Possibly the source and dest object parameters as well.  From there you should be able to mimic all the functionality of the Map function, although it will take a while to translate everything.\r\n\r\nI'm working on converting them now, but theoretically it should work.  I need to keep converting every one to see how far I can go.  I know something like the Enum mapper has a bunch of if statements that can be taken out  and just build a single expression, so I'm pretty sure Collection Mappers can do the same.\r\n\r\nAs far as the overlap with LinqMappers I'm not sure as well.  But after all is said and done and we can re-use code I would suggest an attribute or interface to say ILinqExpression and only use ones of those types for ExpressionVisitor.  But for now I say keep them completely separate until all is said and done on IObjectMapper"}}