1

私は最近、この特定のパターンに関する多くの「憶測」と雑談を見てきました ( Dojo ツールキットを学び始めて以来) が、その問題に関する明確な情報を見つけることができません。これは、頻繁に発生する「有害な」(私ではなく彼らの) MVC パターンに対する解決策であると言う人もいます。Interface-Compute によって解決される MVC の「一般的な」全体像の問題をいくつかリストします。このサイトを見つけて読みましたが、長所と短所について全体像を把握することはできません.

入出力

ビュー コンポーネントは静的コンポーネントとして定義され、ユーザーからの入力を直接受け付けることはありません。つまり、ユーザー入力への反応は、ユーザー刺激を提示するコンポーネントとは別のコンポーネントによって処理されます。しかし、GUI プログラミング環境は、このように入力コンポーネントと出力コンポーネントの間に明確な線を引くことはありません。適切に設計された GUI プログラミング環境は、ユーザー インターフェイス機能のネストされたコンテナーにコンポーネント化されます。

ブラウザを無視

いわゆる「リッチ インターネット アプリケーション」の構築をサポートすることを目的とした Web アプリケーション フレームワークを考えると、フレームワーク全体がサーバーに常駐するため、明らかにビューとコントローラーの両方がサーバーに実装されます。これにより、ブラウザは設計モデルから完全に除外されます。これが私たちの設計のイメージである場合、ブラウザは優れた出力機能を備えた端末として機能するだけです。

等...

Dojo Toolkit、Node.js、その他の洗練されたサーバー側コードのようなすべての JavaScript 開発について疑問に思っています (私たちはこの種の時代に入り、PHP を使用したサーバー側コードの処理方法を再考する可能性があると思います)。 、Java、Ruby on rails など)。さらに、ブラウザでサーバー側とクライアント側の両方のコードをデバッグできるのは素晴らしいことです。

4

1 に答える 1

1

あなたの引用の文脈を知るために、あなたが提供したリンクを簡単に読みました. 筆者は MVC やオブジェクト指向についての知識がほとんどないことを強く感じます。

モデルとビューは、オブジェクトのコレクション/カテゴリ/ドメインです。各オブジェクトは完全に自己完結型であり、オブジェクト指向の原則に従う必要があります。Controller は、Model オブジェクトとやり取りするための View オブジェクト メソッドを提供します (一般に、アクションは、複雑になる可能性がある多くの共同モデル オブジェクトを変更するためです)。

Interface-Compute が提供するソリューション:

たとえば、マウス クリックの検出が、押されたボタンまたは押されていないボタンを表示するコンポーネントとは別のコンポーネントに実装されている場合、マウス クリックがボタン上で発生したときに 2 つのコンポーネント間で通信するために、重要な機構を構築する必要があります。この問題は、マウス入力の認識とボタンの表示を同じコンポーネントに実装すると解消されます。

オブジェクト指向の原則を実装することには多くの利点があります。これは完全に見逃されたようです。したがって、私が言えることは、彼がオブジェクトを使用してコーディングしたくない場合、MVC は適していない可能性があるということです。

于 2012-08-24T10:17:49.007 に答える