Automapperは.Netの「オブジェクト-オブジェクトマッパー」です。つまり、オブジェクトをクラスから同じものを表す別のクラスにコピーします。
なぜこれが便利なのですか？クラスの複製はこれまでに役立つ/良いデザインですか？
回答:
簡単なグーグル検索でこの例を明らかにしました：
http://www.codeproject.com/Articles/61629/AutoMapper
AutoMapperの完全に有効な使用法を示していますが、これはデザインが悪い場合の例ではありません。レイヤー化されたアプリケーションでは、データまたはビジネスレイヤーにオブジェクトがある場合があり、そのデータオブジェクトの属性のサブセット、またはUIレイヤーでそれらに対する何らかのビューが必要な場合があります。そのため、UIに必要な属性だけを持つオブジェクトを含むビューモデルを作成し、AutoMapperを使用して、より少ない定型コードでそのオブジェクトのコンテンツを提供します。
このような状況では、「ビューオブジェクト」は元のクラスの複製ではありません。それらには異なる方法があり、おそらくいくつかの重複する属性があります。ただし、UIを表示する目的でのみそのビューオブジェクトを使用し、データ操作やビジネスオペレーションに悪用し始めない限り、これは問題ありません。
これをよりよく理解するために読むことができる別のトピックは、CRUDとは対照的に、ファウラーのコマンドクエリの責任分離パターンです。データを照会してデータベースで更新するためのさまざまなオブジェクトモデルが意味をなす状況を示しています。ここで、あるオブジェクトモデルから別のオブジェクトモデルへのマッピングは、AutoMapperなどのツールによって実行することもできます。
クラスの複製はこれまでに役立つ/良いデザインですか？
データレイヤーで使用されているのと同じクラスを使用するのではなく、UIレイヤーで使用する別のビューモデルクラスを持つことをお勧めします。UI / Webページには、データエンティティに厳密に関連していない他の情報を表示する必要がある場合があります。この追加のクラスを作成することで、要件が時間の経過とともに変化するときにUIを簡単に微調整できるようになります。
AutoMapperの使用に関しては、次の3つの理由で個人的に回避しています。
より一般的なサイレント障害
AutoMapperはプロパティ間を自動的にマッピングするため、あるクラスのプロパティ名を変更し、他のクラスを変更しないと、プロパティマッピングがスキップされます。コンパイラーは知りません。Automapperは気にしません。
静的解析の欠如
そのため、対処するための大きなコードベースが与えられました。100万のプロパティを持つ100万のクラスがあります。使用されていないか、重複しているように見えます。Visual Studioの「すべての参照を検索」ツールを使用すると、プロパティが使用されている場所を確認し、アプリケーション全体がどのように連携するかのマップを構築できます。ただし、Automapperが使用されているため、プロパティの半分への明示的な参照はありません。私の仕事は今ではかなり大変です。
複雑さを増す後期要件
Automapperは、1つのクラスから別のクラスに値をコピーするだけの場合（開発の開始時によくあることです）、時間の経過とともに変化する要件を覚えていますか？アプリケーションの他の部分から値を取得する必要が生じた場合、おそらくログインしているユーザーや他のコンテキスト状態に固有のものでしょうか？
アプリケーションの起動時に1対1のクラスマッピングを作成するAutoMapperのパターンは、こうした種類のコンテキスト固有の変更には適していません。はい、おそらくそれを機能させる方法がありますが、私は通常、自分でロジックを書く方がより簡潔でシンプルで表現力豊かだと感じています。
要約すると、Automapperが1つのクラスを別のクラスに手動でマッピングする時間を30秒節約する前に、これについて考えてください。
プログラミングとは、コンピューターに何をしてほしいかを他の人間に伝える技術です。-ドナルド・クヌース
これを念頭に置いて、「今日AutoMapperは役に立ちますか、明日は役に立ちますか」と自問してください。
私の経験では、誰かが「ボイラープレートが多すぎる」と不平を言ってAutoMapperを使用したい場合、それは次のいずれかです。
しかしながら：
静的に型付けされた言語を選択した場合は、その言語を活用してください。リフレクションとAutoMapperのような魔法のAPIの過剰使用に起因するミスを防ぐのに役立つ言語のコントロールを回避しようとする場合、それは単に、ニーズに合わない言語を選択したことを意味します。
また、MicrosoftがC＃に機能を追加したからといって、すべての状況で公正なゲームであることや、ベストプラクティスをサポートしていることを意味しません。たとえば、リフレクションと「動的」キーワードは、それなしでは必要なことを達成できない場合に使用する必要があります。AutoMapperは、それなしでは解決できないユースケースのソリューションではありません。
それで、クラスの複製は悪い設計ですか？必ずしも。
AutoMapperは悪い考えですか？そのとおり。
AutoMapperの使用は、プロジェクトの体系的な欠陥を示しています。必要な場合は、設計をやめて考えてください。常に、より良く、より読みやすく、より保守しやすく、バグのないデザインを見つけるでしょう。
ここでのより深い問題があります：例えば：C＃とJavaは、すべてのタイプの名前ではなく、構造によって区別でなければならない/ほとんどを主張しているという事実class MyPoint2Dとclass YourPoint2D、彼らはまったく同じ定義を持っている場合でも、別のタイプのですが。必要なタイプが「xフィールドとフィールドを持つ匿名のものy」（つまりレコード）である場合、あなたは運が悪いです。したがって、をにYourPoint2D変換するMyPoint2D場合、次の3つのオプションがあります。
this.x = that.x; this.y = that.y選択肢1は少量でも十分簡単ですが、マッピングする必要があるタイプの数が多い場合はすぐに面倒になります。
選択肢2は、コードを生成するためにビルドプロセスに追加のステップを追加し、チーム全体がメモを取得するようにする必要があるため、あまり望ましくありません。最悪の場合、独自のコードジェネレーターまたはテンプレートシステムもロールする必要があります。
それはあなたに反射を残します。あなたはそれを自分でやるか、AutoMapperを使うことができます。
Automapperは、皇帝が文字通り裸で走り回っているライブラリ/ツールの1つです。派手なロゴをすり抜けると、手作業ではできないことを実行しても、より良い結果が得られることがわかります。
メンバーの自動マッピングをどのように示唆しているかは完全にはわかりませんが、ほとんどの場合、追加のランタイムロジックと考えられるリフレクションが含まれます。これは、時間の節約と引き換えに重大なパフォーマンスの低下になる可能性があります。一方、手動マッピングは、コンパイル時間のかなり前にヒントを実行します。
AutoMapperにヒントがない場合は、コードを使用してマッピングを設定し、フラグを設定する必要があります。すべてのセットアップとコード作業をわざわざ行うつもりなら、手動マッピングに比べてどれだけ節約できるかを疑問視する必要があります。