Brakujący członek w AutoMapper 2.1.265

Question

W AutoMapper 2.0 użyłem Profili, aby skonfigurować moje mapowanie. Używam SourceMemberNameTransformer i DestinationMemberNameTransformer, aby pasowały do ​​moich nazw właściwości źródłowych i docelowych.

W wersji 2.1.265 te właściwości nie są już w profilu. Czy ktoś wie, dlaczego zostały usunięte? Ale co ważniejsze, w jaki sposób mogę powielić tę funkcjonalność.

Edit

Szukałem na SourceMemberNamingConvention i DestinationMemberNamingConvention, ale nie mogę znaleźć żadnej dokumentacji, jak tych prac. Czy ktoś ma doświadczenie przy użyciu niestandardowego INamingConvention?

Edycja 2

członkowie źródłowe są generowane z bazy 3rd party. Zazwyczaj używają one wszystkich małych nazw kolumn z podkreśleniami między wyrazami. Czasami tracą podkreślenia, czasami rzucają losowo wielkie litery.

Członkowie miejsca docelowego starają się przestrzegać konwencji nazewniczych .NET w jak największym stopniu. Usunięto podkreślenia, a pierwszy znak po znaku podkreślenia był pisany wielkimi literami. Wprowadzono dodatkowe zmiany w celu ułatwienia czytania nazw członków.

Aby rozwiązać ten problem, ustawić

SourceMemberNameTransformer = name => name.Replace("_", "").ToUpper() 
DestinationMemberNameTransformer = name => name.ToUpper() 

Edycja 3

Więcej informacji dla osób z przyszłości.

Sprawdziłem źródło, aby zobaczyć, jak użyto INamingConvention. Sposób, w jaki został zaprojektowany, jest trochę mylący. Interfejs jest befined jak

public interface INamingConvention 
{ 
    Regex SplittingExpression { get; } 
    string SeparatorCharacter { get; } 
} 

Jednak AutoMapper nie użytkownikowi pełną definicję interfejsu zarówno SourceMemberNamingConvention i DestinationMemberNamingConvention

to ma każdy członek rodzaju i przeznaczenia stosuje DestinationMemberNamingConvention.SplittingExpression. Następnie bierze te części meczowe i wywołuje string.Join używając SourceMemberNamingConvention.SeparatorCharacter. Następnie próbuje dopasować elementy typu źródła do elementów typu miejsca docelowego.

To bardzo szczegółowy przegląd tego, co się dzieje i nie jest próbą opisania pełnej funkcjonalności. Ma jedynie na celu pokazanie, w jaki sposób jest używana INamingConvention i aby pokazać, że nigdy nie są używane SourceMemberNamingConvention.SplittingExpression i .

Jeśli nie można przekształcić elementów docelowych za pomocą tej strategii, należy ręcznie zmapować właściwości jako sugerowane jako nemesv's answer.

Answer 1

Szwy tej funkcji są usuwane, patrz GitHub.

EDIT Przepisz po aktualizacji pytanie:

Może wbudowanego LowerUnderscoreNamingConvention rozwiązuje problemu. Przetestowałem z tym kodem:

Mapper.Initialize(c => 
    c.SourceMemberNamingConvention = new LowerUnderscoreNamingConvention()); 
Mapper.CreateMap<Source, Dest>(); 
var test = Mapper.Map<Dest>(
    new Source() { test_Another_Prop = "test", test_this_prop = "test" }); 

Gdzie Source i Dest:

public class Source 
{ 
    public string test_this_prop { get; set; } 
    public string test_Another_Prop { get; set; } 
    public string test_wronglynamedprop { get; set; } 
} 

public class Dest 
{ 
    public string TestThisProp { get; set; } 
    public string TestAnotherProp { get; set; } 
    public string TestWronglyNamedProp { get; set; } 
} 

Jeśli nie obejmuje wszystkich przypadków można sprawdzić, jak to jest realizowane in the source i tworzyć własne convetion.

EDIT: Po Komentarz:

Gdy konwencja nie ma zastosowania można spaść z powrotem ręcznie nadpisać szczególne przypadki:

Mapper.CreateMap<Source, Dest>() 
    .ForMember(d => d.TestWronglyNamedProp, c => c 
    .MapFrom(s => s.test_wronglynamedprop)); 

nie widzę innego wyjścia w obecnej wersji. Ponieważ o ile nic nie zastąpi MemberNameTransformer s.