AutoMapper-ベストプラクティス

4245 ワード

プロファイル制御により、定義モデルmapをロードするファイルを制御します.
mapファイルが存在するプログラムセットを指定する
そしてMapperの初期化方法で追加
  
    
    
    
  

次に、これらのプログラムセットをロードしてProfileの派生クラスを継承する方法を定義します.
    public static void LoadConfig(string sectionName = "autoMapper")
        {
            var config = ConfigurationManager.GetSection(sectionName).As();
            var assemlies = config.Keys
                .Cast()
                .Select(e => config[e])
                .Where(e => !e.IsNullOrEmpty())
                .ToArray();
            Mapper.Initialize(cfg => cfg.AddProfiles(assemlies));
            Mapper.AssertConfigurationIsValid();
        }

そしてMVC種目ならglobal.asaxでのApplication_Startメソッドで上記のメソッドを呼び出します.
次に、モデルmapが必要な場所でモデル間のmap関係を事前に作成するだけです.
  /// AutoMapper    
    public class AutoMapperProfile : Profile
    {
        ///     
        public AutoMapperProfile()
        {
            CreateMap()
                .ForMember(t => t.Enabled, opt => opt.Ignore())
                ;
        }
    }

モデルマッピングの定義におけるMapFromとResolveUsingの違い
パラメータが異なる
MapFromはアトリビュートの直接変換に適しておりnullかどうかを確認します
ResolveUsingは複雑な属性変換に適しておりnullかどうかはチェックされません
MapFromを使用して変換中に放出されたnullに関連する異常が発生すると、内部でエラーが発生していることが分からないように自動的に処理されます.
これはresolverをカスタマイズし、ResolveUsingを使用してマッピング変換できます.
次の参照先:http://blog.travisgosselin.com/automapper-mapfrom-vs-resolveusing/
When specifying the mapping creation between two objects you have two possible approaches that are often used interchangeably by some without understanding the difference: You can use the “ResolveUsing” method: Mapper.CreateMap().ForMember(d => d.DestPropX, o => o.ResolveUsing(s => s.SourcePropY)); You can use the “MapFrom” method Mapper.CreateMap().ForMember(d => d.DestPropX, o => o.MapFrom(s => s.SourcePropY)); In 90% of the time, these are going to and do the exact same thing, and you won’t have to worry. However, if you are doing a more complex flattening exercise for a property that won’t flatten by convention the “MapFrom” includes NULL checks all the way through the object graph. For example: ForMember(d => d.DestPropX, o => o.MapFrom(s => s.Person.Address.State)); This scenario will not blow up your application if Person or Address is NULL, but instead NULL will be mapped over to the DestPropX safely. AutoMapper automatically catches the thrown NULL reference exception and hides it from you. That sounds AWESOME. But you need to be aware of the overhead price you pay in performance for using Exceptions during your normal workflow of your application. Consider the scenario where I have a list of 1,000 objects to convert, all with a NULL Person property, in which cases we are looking at 1,000 Null reference exceptions that must be eatin’ inside your app. In my own experience, under the wrong scenario where this was multiplied many times, I had a single web service call that took about 10 sec. Upon investigating, I found that due to the number of exceptions thrown for NULL checks, my web service transformation was taking an extra 5 sec. I could easily get my 50% performance boost by doing some manual NULL checks with ResolveUsing: ForMember(d => d.DestPropX, o => o.ResolveUsing(s => s.Person != null ? s.Person.Address.State : null )); By manually doing my null checks, I have avoided the onslaught of exceptions, and get the large performance boost. While that is one large workflow difference, often the ResolvingUsing is used for custom logic that occurs during the mapping, while the MapFrom is generally reserved for flattening operations. If you expect to never have a null, then you may consider using ResolveUsing in order to get an exception that bubbles up when it occurs, and lets you know there is likely a problem. This way the problem is not hidden from you with the large performance hit on the side.