Closed StillLearnin closed 5 years ago
I suppose a case could also be made to simply return without setting anything.
Hi
The problem of the null
values is much broader but it's worth to discuss it:
How to detect if the given value could or could not be null. Additional annotations (such as CanBeNull or NotNull from Resharper) or C# 8.0 not-null reference could be useful. This could also help to generate a contract guard code.
If the source is null then the method should return a null or new (empty) instance of the destination type? Should the destination object be overwritten for update-mapping?
How to handle the null reference of sub-properties? Should the ?.
operator be applied?
Been mulling over your reply and the excellent questions it contains. It does seem that the problem of null
is much broader than what I first thought.
I generally handle reference type sub-properties using another mapper injected for them. This means that in my experience the null
problem will be handled by a sub-mapper. So leaving sub-properties aside for the moment, I think the question becomes:
Options:
null
become an object
when mapped?AddressMapper
inside a ContactMapper
to resolve the ContactModel.Address
property, if the Address
object was removed (set to null
) by the UI, the AddressMapper
wouldn't properly remove the Address
from the ContactEntity
.Hi Sorry for the late reply. I was thinking about this problem and I decided to not implement anything related to this null handling. The main idea behind the MappingGenerator is to facilitate a simple scaffolding of mapping method based on the simple and obvious rules and allows to customize generated code. Everybody has different expectations for the null handling and this should be handled by manual adjustment of generated code depending on the given case.
Makes sense to me. Thanks for considering it.
I would find it helpful if null checking code was generated along with the mapping code. Any thoughts on this?
Example:
or