ASP.NET MVCのMODELが、このようなデータベースと通信するアプリケーションの一部として使用される場合や、このようなデータを配信するアプリケーション間を「移動」するビジネスオブジェクトとして使用される場合があるのはなぜですか。
質問する
834 次
6 に答える
4
MVCは、Smalltalkが始まってから、ご存知のように、非常に異なるアーキテクチャを記述するためによく使用されるようになるまで、さまざまな方向に進化してきました。
Martin Fowlerは、MVCの進化についてここでブログを書いています。http://martinfowler.com/eaaDev/uiArchs.html
ここにMVC、MVP、MVVMの違いの説明があります：http： //joel.inpointform.net/software-development/mvvm-vs-mvp-vs-mvc-the-differences-explained/
私の10c：
ASP.NET MVC 3の多くの例は、MVCよりもMVVMパターンに密接に対応しています。MVVMでは、ViewModelsは各ビューのデータ固有に合わせて調整されます（つまり、「ViewModels」は単なるドメインモデルではなく、検証ルール、フィールドプロンプト/名前、フィールドの可視性などのビュー/プレゼンテーション層の懸念事項で装飾されます）。
（MVCに戻る）バックエンドの階層化をあまり必要としない小規模なデータ中心のプロジェクトでは、Mはいくつかのルールを持つORMモデル（たとえば、いくつかの自動生成されたPOCOを備えた.EDMX）と同じくらい単純にすることができます。この場合、MVCはほぼアプリケーションアーキテクチャと見なすことができます。
しかし、MVCを使用する大規模なプロジェクトでは、モデルの元の（Smalltalk）「M」が他のいくつかのレイヤーに分割されます。たとえば、ドメインエンティティ、サービスファサード、サービス（SOAなど）、ビジネス、データ層などです（ここでは、 M VCはプレゼンテーション層のパターンであり、Mはシステムの残りの部分です）。したがって、たとえばこのようなプロジェクトでは、MVCプロジェクトの「モデル」フォルダーは、システムの「バックエンド」との通信に使用されるプロキシサービス参照とプロキシドメインエンティティ、またはこの通信の抽象化である可能性があります（たとえば、を参照してください）。複合アプリケーションブロックで使用されるサービスエージェント/サービスファサード）。
于 2012-06-17T19:58:37.023 に答える
3
これらは両方とも、MVCの「モデル」コンポーネントが実行することになっていることの一部であるためです。
大まかに言えば、3つのコンポーネントの役割は次のとおりです。
- モデルは、ドメインロジック全体を実装します。これには通常、永続性（データベースなど）だけでなく、ビジネスロジックも含まれます。完全なMVCでは、ドメインデータへの変更はすべてモデルルーチンとして実装されます。
- コントローラは、UI（または公開されているインターフェイス）から入力を読み取り、それを正しいモデルルーチンにディスパッチします。
- ビューは、生のモデルデータをUIがパブリックインターフェイスに表示できるものに変換します。
多層アーキテクチャとは異なり、MVCはドメインロジックとデータの永続性を区別しません。モデルは両方を実装します。
ただし、実際には、ほとんどのMVC実装は100％正確ではありません。モデルがデータアクセス層に縮小され、ドメインロジックの多くがコントローラーで発生するのはよくあることです。実際、入力検証（コントローラーのジョブ）がどこで終了し、実際のドメイン処理（モデルのジョブ）が開始されるかが不明な場合があります。データがモデルからビューにどのように流れるかについても少し論争があります-コントローラーはモデルデータを読み戻してビューに渡しますか、それともモデルはその結果をビューにアクティブに渡しますか？または、ビューをアクティブな部分にして、モデルにデータをクエリする必要がありますか？
于 2012-06-17T20:03:52.903 に答える
2
Model View Controllerパターンでは、コントローラーが先頭に立っています。レンダリングされるビューとそのビューに渡されるデータを決定します。
ほとんどの場合、データベースを使用してモデルを永続化するアーキテクチャに慣れています。しかし、それは必須ではありません。モデルは、他の何か（XMLやWebサービスなど）に永続化することもできます。
Mはビューモデルを表すこともできます。つまり、実際のモデルをデータベースからコントローラー、ビューに渡すのではなく、ビュー用に特別に調整されたモデルを使用しているということです。
ドメイン駆動設計を使用する場合、コントローラーはドメイン内の関数を呼び出すためだけに機能します。ドメインモデルには実際のビジネスロジックが含まれており、永続ストア（リポジトリ）にアクセスして新しいオブジェクト（ファクトリ）を作成するためのサービスを公開しています。その場合、コントローラーは可能な限りフラットにする必要があります。
于 2012-06-17T20:04:37.097 に答える
2
モデルは、MVCの中で最も理解しにくい部分です。
ビジネスモデルの観点から考える人もいるので、モデルにデータベースと直接対話させるようなことをします。
他の人はビューモデルの観点から考えるので、最終的にはより単純なデータクラスになります。
個人的には、関心の分離がより適切に行われると思うので、私は2番目のグループにいます。
于 2012-06-17T20:05:08.700 に答える
1
最初の図は、コントローラーがデータベースからモデルを作成してから、モデルがビューに渡されることを示しています。2つ目は同じですが、単純なビューのみが含まれています。
あなたはチェックしたいかもしれません：
于 2012-06-17T19:59:38.417 に答える
1
私はそれを「ビジネスロジック」または「ユーザーがサイトから取得するものであり、見た目ではない」と考えています。
于 2012-06-17T20:01:15.187 に答える