どう思いますか?ドメインとプレゼンテーションモデルをどのようにマッピングしますか?
3 に答える
AutoMapperを使用することには不利な点もあり、これらの不利な点のいくつかは、(コードを明示的に記述するのではなく)慣例によるプログラミングに一般的に当てはまります。
2つのC#クラスがあるとします-
namespace MyDtoNamespace {
public class MyClass {
public int Id { get; set; }
}}
namespace MyBusinessLayerNamespace {
public class MyClass {
public int Id { get; set; }
}}
AutoMapperは、明示的な構成をほとんど必要とせずに、これら2つのクラス間を適切にマッピングします。
しかし後で、開発者がこれらのIdプロパティの1つを別の名前に変更することを検討していると言います。
namespace MyBusinessLayerNamespace {
public class MyClass {
public int MyNewIdentifierVariableName { get; set; }
}}
Visual Studioで参照を注意深く検索し、これらの参照に対する名前の変更の影響を検討しますが、MyDtoNamespace.MyClass.IdはMyBusinessLayerNamespace.MyClass.Idを明示的に参照していないため、表示されません。
Visual Studioまたは別のツールが、ソリューション内の変数のすべての出現箇所の名前を自動的に変更すると、AutoMapperマッピングが壊れます。
これは実行時にのみ確認でき、コンパイル時の問題はありません。理想的には、マッピングが期待どおりに機能することを確認するための単体テストがありますが、それでも、リファクタリング中に実行時エラーが発生する可能性があるため、明示的なマッピングコードを作成することをお勧めします。
私は確かにAutoMapperを完全に回避することを主張しているのではなく、慣例によるプログラミングの大きな問題に注意しているだけです。
別のオートマッパーの質問からの回答の一部を引用する:
あるタイプのオブジェクトがあり、最初のタイプのプロパティを使用して別のタイプのオブジェクトのプロパティを設定する場合は、次の2つの選択肢があります。
- このようなマッピングを行うためのコードを手動で記述します。
- これを自動的に処理するツールを使用してください。
AutoMapperは2の例です。
LINQ to Objectsは1の例です。これは、バニラオブジェクトからオブジェクトへのマッピングコードを作成するよりも少し苦痛が少ないだけです。
長所と短所の観点から:
Automapperは、規則を使用してデフォルトのマッピングを決定するため、LINQと比較して作成する必要のあるコードの量を大幅に削減する必要があります。LINQを使用して、これらのデフォルトのマッピングを定義する必要があります。
LINQを使用すると、両方向のマッピングを定義する必要があります。規則が使用されている場合、Automapperはこれを自動的に処理できる必要があります。
すべてのサードパーティのdllと同様に、Automapperを使用すると、別の依存関係が導入され、小さな学習曲線が必要になります(これまでLINQを使用したことがない開発者にも学習曲線があることに注意してください)。
Automapperは、LINQ(およびLINQ2SQL)と組み合わせて使用できることに注意してください。これは、より細かい点のいくつかを説明するさらに別のAutomapperの投稿です。
http://bhavinsurela.com/linq-and-automapper-view-model-and-data-model/があなたが探しているものかもしれません。