1

私はMVP、MVVMについて読んでおり、いくつかの練習プロジェクトでasp.netMVCを使用しています。これらのパターンは主にUIパターンと呼ばれ、ビュー（MVC内）のみがUIであり、モデルはデータアクセス層+ BLLであると考えていたため、少し混乱します。私の質問は、モデルとしてEntity Framework（edmx）を使用する場合、データアクセス（DAL）用に別のレイヤーが必要な理由と、このシナリオでこのデータアクセスレイヤーが実際に何をするのかということです。

4

3 に答える 3

1

MVCおよびその他は、外部ソースからの要求を受け入れて結果を表示することが主な使命であるため、UI/プレゼンテーションパターンと見なされます。これらのパターンのM部分は、通常、ビューの作成に役立つDTO（データ転送オブジェクト）として使用される単純なモデル（ビューモデルとも呼ばれます）を指します。

ビジネスロジックは、それが単なるCRUD操作よりも強力である場合、一般的にこれから分離されます。これにより、さまざまな種類のフロントエンドアプリ（ここではMVCサイト、そこには実際の電話/タブレットアプリ）がさまざまな方法でデータを操作できるようになります。

言い換えれば、MVCなどは、実際に何かを実行するビジネスロジックの単なるスキンにすぎません。

EF部分をプロジェクトの残りの部分から分離することが理にかなっているかどうかを自問する必要があります。データに対してCRUD操作以上のことをしているのなら、そうだと思います。

于 2012-06-24T16:00:36.087 に答える
1

EFはデータアクセス層であると同時にモデルであるため、個別のDALは明示的に必要ありません。モデルにPOCOを使用する場合は、これらのオブジェクトの永続性を処理するためのレイヤーが必要です。したがって、NHをOR / Mとして使用する場合、モデルは単純にPOCOオブジェクトで構成され、NHがDALになります。通常、NHは別のレイヤーに隠されていますが、これは実際には必要ありません。GUIに関しては、エンティティはバインディングなどに直接使用されません。MVVMは、GUIとドメインモデルの間のレイヤーとして機能し、モデルから必要なすべてのデータを提供するViewModelを導入します。 GUI。

于 2012-06-24T16:07:12.697 に答える
1

実際には、ビューとコントローラーの両方がUIを処理します。基本的に、モデルレイヤーを除くすべては、UIに関するものです。また、RESTAPIのようなものも単なる異なる種類のユーザーインターフェイスであることを理解する必要があります。

あなたの研究に関しては、Model2MVCとHMVCをパターンとしてもっとよく見ることをお勧めします。前者は、従来のMVCに最も近いものであり、Webで実行できます。後者には非常に興味深いユースケースがあり、再利用性の問題を解決します（分散システムでもある程度の可能性があります）。

さて、主な質問です。

次の機能を利用できるため、ドメインビジネスロジック（ドメインオブジェクト内）をデータアクセスロジック（データマッパー内）から分離します。

  • コードの分離、関心の分離
  • 独立してユニットテストする機能

基本的に、これによりコードベースを作成できます。特定の変更（キャッシュの追加やモデルレベルの承認チェックなど）を追加しても、コードベース全体を書き直す必要はありません。

また、ストレージメカニズム自体がはるかに柔軟になります。特定のドメインオブジェクトのデータが保存されている場所を簡単に変更できます。たとえば、ユーザーの詳細と認証をnoSQLデータベースに移動できます。これは、ビジネスロジックの動作に影響を与えることはありません。大規模なチームで作業している場合や古いコードを維持している場合、システム全体を把握してこの知識を最新の状態に保つことは非常に難しいため、これは重大な問題になります。

データアクセス層の機能については、ドメインオブジェクト（ドメインビジネスロジックを含むもの）を取得し、それらからデータを格納するか、データソース層の情報を取得します。

また、私は調査/監視することをお勧めします：

免責事項：私の第一言語はPHPであり、MVC構造の理解を形作ったWebのコンテキストでのMVC関連のパターンの経験しかありません（Web自体の明らかな制限のために主にModel2バリアントで） 。

于 2012-06-24T16:46:33.397 に答える