AutoMapper optimisation or an issue?

[antonlyhin]

Good evening Jimmy, thank you for great job on AutoMapper.
Today I stopped reading you article on AutoMapper's Design Philosophy and got some questions.

Several statements from you blogpost:

1. It assumes that the destination member names follow the exact name of the source type.
2. AutoMapper works because it enforces a convention. It assumes that your destination types are a subset of the source type. It assumes that everything on your destination type is meant to be mapped. Mar 25, 2019
3. On top of this, we would get null reference exceptions fairly frequently - when there was missing data for whatever reason, our simple assignment expressions would blow up (this was also before the null conditional operator).

Reference: https://jimmybogard.com/automappers-design-philosophy/#:~:text=AutoMapper%20works%20because%20it%20enforces,is%20meant%20to%20be%20mapped.

Can you please clarify this article?

1. Destination member names follow the exact name of the source type. Isn't this responsibility of .NET Framework, C# is strongly typed language?
2. This statement is also not always true. Do you know that MVC DI extension checks destination type mappings, but Local and Profile configurations do not.
3. Statement about NullReferenceExceptions is also a bit confusing because you state that "On top of this, we would get null reference exceptions fairly frequently - when there was missing data for whatever reason, our simple assignment expressions would blow up" Mar 25, 2019 and here PR NullReferenceException mapping null with context.Mapper #3057 but context.Mapper.Map_{(null) throws NullReferenceException. Introduced in 8.1.0 on Apr 29, 2019.}

Can you please explain these ambiguity and if I'm missing something here.
Can't we just love development tools and AutoMapper in particular because they make contracts (model mapping contracts) clear and intuitive? I guess love is the answer. :)

[jbogard]

1. Destination member names follow the exact name of the source type. Isn't this responsibility of .NET Framework, C# is strongly typed language?

I'm not sure what you mean here. It's the responsibility of the person creating the destination types. I can name destination members differently, nothing in C# enforces a convention.

2. This statement is also not always true. Do you know that MVC DI extension checks destination type mappings, but Local and Profile configurations do not.

I don't know what you're referring to as "Local" and "Profile" configurations, nor what this has to do with MVC DI.

3. Statement about NullReferenceExceptions is also a bit confusing because you state that "On top of this, we would get null reference exceptions fairly frequently - when there was missing data for whatever reason, our simple assignment expressions would blow up" Mar 25, 2019 and here PR NullReferenceException mapping null with context.Mapper #3057 but context.Mapper.Map_{(null) throws NullReferenceException. Introduced in 8.1.0 on Apr 29, 2019.}

That is a very specific scenario of wrapping custom extensions (resolvers, type converters) with try/catch. We don't do that anymore. We still handle nulls in foo.Bar.Baz so effectively we have:

dest.FooBarBaz = src?.Foo?.Bar?.Baz ?? default;