14

MVC に関する多くの出版物を読みましたが、なぜ「コントローラー」が必要なのか、まだはっきりと理解できません。

私は通常、クライアント サーバーモデルでアプリケーションを作成します。

サーバーにはすべてのビジネスロジックが含まれており、GUI については何も知りません。それは主な仕事をし、可能な限り移植性があります。

clientは GUI であり、サーバーにバインドし、ユーザーとやり取りし、ユーザーからサーバーにコマンドを送信します。

私はこのアーキテクチャが好きですが、なぜ人々がclientとserverの間にもう 1 つの媒体 (コントローラーのように見える) を本当に必要とするのか理解できません。

UPD:簡単な例: データロガーを作成する必要があるとします。データは COM ポートから取得され、何らかのプロトコルによってエンコードされます。単純なログ ウィンドウに受信メッセージを表示する必要があります。

どうやって作るのですか：

サーバーには次のアイテムが含まれています。

  • Data_receiver: 実際には COM ポートから生データを受け取りますが、これはインターフェイスであるため、他のソースからデータを受け取る別のクラスを作成できます。
  • Data_decoder: 生データを受け取り、結果のデコードされたメッセージを返します。これもインターフェイスであるため、エンコード プロトコルを簡単に変更できます。
  • Data_coreData_receiver:とのインスタンスを使用してData_decoder、クライアントにシグナルを送信します。

クライアントには次のアイテムが含まれています。

  • アプリケーション コア: Data_receiver(COM ポートに接続するもの) のインスタンスを作成しData_decoder、 (およびインスタンスData_coreを参照する)、GUI シンプル ログ ウィンドウ (を参照する) も作成します。Data_receiverData_decoderData_core
  • GUI の単純なログ ウィンドウ: にバインドします。Data_coreつまり、それによって発せられる信号をリッスンし、受信したデータを表示します。

MVCについて読んだことを理解したので、GUIは実際にから受信したメッセージを受け取るべきではありません。コントローラーがそれを行ってからデータをGUIに渡す必要があるData_coreためです。しかし、GUI がこのデータをモデルから直接取得すると、どのような悪いことが起こるのでしょうか?

4

4 に答える 4

2

過去に何度も同じ質問を自問してきました。最近、JSP モデル 2 アーキテクチャについて読んでいます。ウィキペディアのエントリには、次のように記載されています。

J2EE プラットフォームの Web 層テクノロジに関する文献では、「モデル 1」および「モデル 2」という用語が説明なしで頻繁に使用されます。この用語は、JSP ページの 2 つの基本的な使用パターンを説明した JSP 仕様の初期のドラフトに由来します。用語は仕様書から姿を消しましたが、一般的に使用され続けています。モデル 1 とモデル 2 は、クライアント層からの要求をディスパッチしてビューを選択するコントローラー サーブレットの (それぞれ) の不在または存在を単に参照しています。

これは基本的に、MVC パターン自体にバリエーションがあることを意味するため、プロジェクトに応じて MVC または MV パターンをいつでも適用できます。ただし、適切な MVC アーキテクチャには実際にコントローラーが必要です。これは、モデルとビューが互いに直接やり取りしてはならないためです。

于 2015-08-15T10:31:56.427 に答える
1

クライアント/サーバー パターンの詳細を読む際に、MVVMパターンを思い浮かべます。単体テストを実行する場合は、VM (ViewModel) をコントローラーと見なすことをお勧めします。

あなたのパターンに従って、Data_receiver、Data_decoder、および Data_core と呼ぶサーバー コード内に、従来のクライアント/サーバー パターン、Controller、Model、および View が存在します。「クライアント」には、コントローラーとビューがあります。

サーバー コードから、COM からの信号とデータを受信およびデコードするコントローラー、コントローラーがデータベースとの間でデータを送受信するモデル、生データをエンコードおよびフォーマットするビューを分離すると便利です。モデルから。

Don't Repeat Yourself (DRY) 原則に従うと、コードまたは責任を繰り返すコードのサーバー部分とクライアント部分の両方にコントローラー コードがあることに気付くかもしれません。

さまざまなテストを添付できるように、テスト駆動開発方式で開発を個別のパーツに分割する場合に役立ちます。

于 2012-12-02T19:58:05.820 に答える
1

「クライアントサーバー」はMVCとは何の関係もありません。

私はそれを次のように理解しています：

  • これModelは、データを構造化する方法です。
  • はView目に見える表現です。(GUI)
  • はControllerロジックを使用してビューやその他のロジックを制御します。

その背後にあるアイデアは、視覚的表現をロジックから分離することです。したがって、ビューを取得するときにロジックを複製する必要はありません。...そのため、クライアント側でのみ MVC を使用し、コントローラーが必要な場合があります。これは、すべての魔法が発生する場所だからです。

于 2012-12-02T18:02:20.167 に答える
-1

「クライアントとサーバーの間にもう 1 つのレイヤーが必要な理由」についての誤解を正したいと思います。

次の行をたどれば、MVC がアーキテクチャの三角形モデルであることは明らかです。

View は Model にリクエストを要求し、Model は Controller に要求し、Controller はそれを処理して View に送り返します。

The Model is the way you structure your data.
The View is the visible representation. (GUI)
The Controller uses the logic to control the view and/or other logic.

よろしく、 Pavan.G

于 2012-12-03T09:21:44.683 に答える