Entity（Persistent）オブジェクトをDTOオブジェクトに変換する必要がありますか？次のように

Question

私のプロジェクトが積層されている： -

DAL (Entity) - >BLL (DTO) - >ApplicationComponent (ViewModel)。

BLLにアクセスするアプリケーションの複数のコンポーネント（ApplicationComponent）があります。コンポーネントには、Windowsサービス、Webサービス、Web API、およびMVCコントローラが含まれます。 BLLにDALからそれらを通過する間

私はDTOオブジェクトへNHibernateEntityオブジェクトを変換しています。この状態をApplicationComponentに渡している間に、BLLは再びViewModelに変換します。

これは、各レイヤーでの懸念事項とデータの処理方法を区別するのに役立ちます。私は、次の理由で表示するNHibernateEntityオブジェクトを返すの賛成ではないです： -

データは、私がなどのパスワード、ユーザタイプ、許可のように非表示（または必要な場合にのみ公開）したい UIにさらされます
• 参照/結合に関しては、NHibernateは、プロパティがアクセスされたときに追加のクエリを実行し、遅延読み込みの使用を無効にします。
• （Entityの）ユーザーに公開されている不要なデータは、混乱とバグの原因となります。
• 持続性の実装がBLL/UIに漏れています。 EntityはUI用に設計されていません。どんな場合でもUIには対応できません。
• Entityで奇数に見えるユーザー入力の検証には、DTOの属性を使用します。

私はこのアプローチには、次のような問題に直面しています： -

• 最大と明白な問題は、同じ機能を持つ冗長オブジェクトです。
• オブジェクトを変換するために、各レイヤーにマッパーメソッドを記述する必要があります。これは、AutoMapperまたは類似のものを使用することによって最小化することができます。問題を完全に解決するわけではありません。

質問： -

• が分離に対するこのANですと（少なくとも最小限に抑える）避けるべき？
• このアプローチが正しい場合、上記の2つの問題を完全に回避する簡単な方法はありません。提案してください。
• この方法が間違っている場合は、修正を提案してください。

参考資料： -

1. Link1た私の理解ではない良いアイデアを表示するEntityオブジェクトを転送することを示唆しています。

2. Link2は、私がすでに合意しているDTOとEntityをマップするよう提案しています。

3. Link3は役に立ちません。

4. Link4は、自動マッパーツールのようなものを使用していることを示しています。しかし、それでも問題は完全に解決されません。

5. Link5は素晴らしい投稿です。それはなぜそれらが私が合意している別々であるべきかを説明します。それはそれによって引き起こされるオーバーヘッドを最小限に抑える方法についてコメントしていません。

6. Link6はもう一度は役に立ちません。

編集1：

私はちょうど可能場合UIであるようEntityを使用することをお勧めしthis優秀答えをお読みください。私のプロジェクトのほとんどにはまだ適用されません。

編集2：

もう一つの優れたpostは私が今やっているようマッピング上の2つの道を行くことをお勧めします。オーバーヘッドを最小限に抑える方法はまだありません。

Answer 1

ケース1：DAL（エンティティ） - > BLL（DTO）：

NHibernateのは、遅延ロードの例のためのvirtualとしての私のエンティティのプロパティを宣言する必要があります。 thisおよびthisを参照してください。ですから、NHibernateがエンティティを使って何か（遅延読み込みのためのプロキシを作成するなど）を行い、それを突き詰めない方が良いと考えられる範囲があります。エンティティをDTOに変換する方が良い。次に、私たちが望むどんな方法でもDTOを使用できます。もちろん、欠点は追加のコーディングとメンテナンスです。

ケース2：BLL（DTO） - > ApplicationComponent（ViewModelに）私たちが持っていたよう

すでに切断さNHibernateは上記（DTOにエンティティをコピーして）、私たちが見るためにデータを渡すためにDTOを再利用するのは自由です。可能な限り、DTOを再利用することができます。可能であれば、新しいViewModelを作成してDTOにマップすることができます。

インターネット上の多くの投稿は、各ビューの新しいViewModelを作成することを強く推奨します。私はコンセプトでこれに同意しますが、私が問題に言及したように、メンテナンスの問題があります。

これは依然として懸念を分離し、適用可能な場合はすべてクラスを再利用することも可能にします。

編集1：

私はthis優秀なポストを見つけました。エンティティを切り離してVMで使用することを提案します。 VMでのEntityの使用に同意しなくても、このトリックを使用してDTOをバイパスできます。問題は、データを遅延読み込みすることです。エンティティは、VMが必要とする正確なデータがわからないため、エンティティを切り離す前にすべてのデータをロードする必要があります。唯一の方法は、良い方法ではないすべてのデータを熱心に読み込むことです。