Set target null if source is null

[StillLearnin]

I would find it helpful if null checking code was generated along with the mapping code. Any thoughts on this?

Example:

public void Map(MyModel model, MyEntity entity)
{
    if (model == null)    //New code to generate
    {
        entity = null;
        return;
    }                    //End new code to generate
    entity.Prop1 = model.Prop1;
    entity.Prop2 = model.Prop2;
}

or

public MyEntity Map(MyModel model, MyEntity entity)
{
    if (model == null)    //New code to generate
    {
        entity = null;
        return entity;
    }                    //End new code to generate
    entity.Prop1 = model.Prop1;
    entity.Prop2 = model.Prop2;
}

[StillLearnin]

I suppose a case could also be made to simply return without setting anything.

[cezarypiatek]

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?

[StillLearnin]

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:

What should be done when the source is null?

Options:

• Return with new instance of target - This is problematic as there are a lot of cases where a reference type has parameters in the constructor and there is no way to infer proper default values. Generating mapping code for these instances is basically impossible. This is also counter intuitive. Why should a null become an object when mapped?
• Return with target unchanged - This seems counter intuitive to me as it leaves no way for the mapper to "remove" the value of a property that has been cleared by the UI. For example, when using an 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.
• Return with target set to null - This seems the most intuitive but would fail in cases where the target is not nullable. However, generating the mapping code this way will work most of the time and throw compile errors when the target is not nullable. Contrast that with the mapping code generated now. With no null checking and no compile time errors, the most common time to discover a null source problem with the mapping code is at runtime.

[cezarypiatek]

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.

[StillLearnin]

Makes sense to me. Thanks for considering it.