コードの最初の移行で異なるレイヤーにPOCOコードを複製

Question

私はエンティティフレームワークを使用することに興味があります - 新しいデータベースでコードを最初に移行し、データとビジネスレイヤーにPOCOコードを複製することに関するいくつかの質問/懸念があります。

アイデアは、私のPOCOエンティティを含むデータアクセスレイヤーに、文字列の長さなどのデータベーススキーマタイプのアイテム、ボックス外で動作しない外部キー関連のアイテム、その他のもので飾られていることです。この層は、スカラー値、エンティティ、集合体、およびIEnumerablesを返すリポジトリとしても機能します。

上記は、リポジトリとのやり取りやビジネスロジックの話などを扱うビジネスレイヤーです。

プレゼンテーションレイヤーが上部にあります。このレイヤーはビジネスレイヤーと通信し、データレイヤーについてはわかりません。すべてが理解できるのはビューモデルです。私はこのレイヤーで、ビューモデルだけを使ってMVCパターンを実装します。

私が実行している問題は、ビューモデルとデータモデルのマッピングをどこで行うべきかと関係しています。プレゼンテーションレイヤーでビューモデルを定義すると、ビジネスレイヤーはそれらが存在することを認識しません。

• ビジネスレイヤでビューモデルを定義する方がよいか、プレゼンテーションレイヤが認識してマッピングを実行できるビジネスレイヤでドメインモデルのセットが必要ですか？
  • ドメインモデルの追加セットは、データレイヤーで定義されたモデルの大きな重複ですか？

Answer 1

プロジェクトの範囲に応じて、私は通常、以下の二つの方法のいずれかを使用：

1）全ての層は別にドメインモデルのセットを有し、全ての層の参照を持っていますそれら。 長所：レイヤはまだ独立しており、モデルの重複はなく、レイヤモデルをマップする必要はありません。 短所：ドメインモデルの変更はすべてのレイヤーに影響します。 DBの変更により表示が中断することがあります

2）各層にモデルがあります。ビジネスレイヤーはそれ自身のモデルをデータレイヤーのレイヤーにマップし、プレゼンテーションレイヤーはそのモデルをビジネスレイヤーのレイヤーにマップします 長所：すべてのレイヤーは1つのことを行い、基底モデルの変更はレイヤーを伝播しません 短所：可能性とマッピングを維持する必要があります

最初のアプローチは、小規模なアプリケーションと「直接更新」シナリオで最も効果的です。二番目のアプローチは、複数の可動コンポーネントを持つ大規模なプロジェクトで効果的です。

P.S. 「ビジネス・レイヤーでのビュー・モデルの定義」は明確なノー・ノーです。