Proposal - Mapster 3.0

I put this to dump my idea here and for discussion to implement new features.

1. Setting per hierarchy

Currently, Mapster can setup only per type pair. Suppose we have Student and School and those types are related each other, we need to create 2 configs for each type. The idea is we should be able to create only one config.

Suppose we create this setting:

TypeAdapterConfig<Student, StudentDTO>.NewConfig().PreserveReference(true);

The setting should apply to both Student mapping and School mapping. Anyway, if we call TypeAdapter.Adapt<School, SchoolDTO>() above setting should not be applies.

To make V3.0 compatible with V2.0, we could use global setting:

TypeAdapterConfig.GlobalSettings.SettingPerType = true;

Above setting will apply setting per type rather than setting per hierarchy.

2. IgnoreAll & IgnoreNavigationProperties & Include

Now we have Ignore to opt-out properties we wouldn’t like to map. The idea is to have opt-in mapping properties. IgnoreAll will ignore all properties. IgnoreNavigationProperties will ignore all properties except primitives. And Include will include properties in mapping even that properties are ignored. This should be useful for projection where normally EF will exclude navigation properties by default and we need to call include to add properties in. We can do following setting.

TypeAdapterConfig.GlobalSettings.Default
                                .When((srcType, destType, mapType) => mapType == MapType.Projection)
                                .IgnoreNavigationProperties(true);

TypeAdapterConfig<Student, StudentDTO>.NewConfig().Include(s => s.Schools);

This IgnoreNavigationProperties & Include setting will also solve #34.

3. Navigation path

The idea is from #35. Map, Ignore, and Include method should accept navigation path, both string and expression. For example:

TypeAdapterConfig<Student, StudentDTO>.NewConfig()
                                      .Include(dest => dest.School.Instructors)
                                      .Map(dest => dest.School.Email, src => src.School.ContactInfo.Email)
                                      .Ignore(dest => dest.School.Name);

4. Inline setting

Currently, we need to separate between config and Adapt method. In some scenario, we might would like to maintain config and Adapt method together. For example:

var result = student.Adapt(config => config.ToType<StudentDTO>().Ignore("Name"));

Inline setting should apply global setting but it should not alter global setting. We can cache setting and compile result using caller information.

For projection, usage might be slightly different.

var result = context.Students.ProjectToType<StudentDTO>(setting => setting.Ignore("Name"));

5. Rename projection method (Done #40)

This should has high impact to everyone who use projection. But in VB, current To method is not fluent.

Dim result = context.Students.Project().To(Of StudentDTO)()

I think To method should be changed to ToType method.

Dim result = context.Students.Project().ToType(Of StudentDTO)() var result = context.Students.Project().ToType<StudentDTO>();

I haven’t prefer VB but I think To method naming is not correct per .NET convention. Another option is to have an alias, but I proposed to rename as it will be less confused.

6. Name mapping strategy (Done #57)

This is for resolving property name. In some cases, we might would like to match proper case to camel case (src.HelloWorld to dest.helloWorld) without manual mapping.

7. Passing run-time value (Done #55)

This is for Mapster to allow passing run-time value ie. this.User.Identity.Name to mapping context.

8. Object to Dictionary & Dictionary to Object (Done #56)

This is to allow conversion between Object and Dictionary.

9. Support dynamic

To convert from/to dynamic.

10. Preserve destination object

Currently when Mapster copy properties from source to destination object, Mapster will create new object for properties. In EF, if we create new navigation objects, EF will create new records. Mapster should preserve object, so when users copy entire object graph, EF will not create new records.

11. Match item when copy list

Continue from 10, when we copy list, Mapster will add new objects to list. EF will create new records for each item. Mapster should be able to identify objects from key and copy to that object.

[chaowlert]

how about create extension methods AdaptFrom?

public static TDest AdaptFrom<TSrc, TDest>(this TDest dest, TSrc src)
{
    return src.Adapt(dest);
}

now you could do something like

var result = new SoBuz().AdaptFrom(barInstance)
                        .AdaptFrom(fooInstance);

NOTE: with this method last one will win. If you need first one win, you might need to create a builder class.

[soenneker]

@chaowlert is the include functionality you describe above in the current version of Mapster? I’m using ProjectToType, losing properties, and then am unable to add properties back to the IQueryable when using ProjectToType again