Javascriptアーキテクチャモデル

Question

これに明らかな欠陥はありますかOO javascriptを使用して実装する予定のアーキテクチャモデル？これはMVPモデルに似ていますが、代わりにモデルの役割が3つのモジュールに分けられます。

キャッシュ（サーバーから再要求する代わりにデータを保存します）
モデル（生データの要求を管理し、可能な場合はキャッシュまたはサーバーから取得します）
修飾子（サーバー上のデータに変更を加えるデータを必要とする要求を処理します）

このモデルを介してデータがどのように流れるかを示す図の場合：

enter image description here

表示

プレゼンターからのデータの要求を必要とする可能性のあるUIをセットアップおよび管理します
表示内容を変更するためのコントロールを設定します。プレゼンターからのデータの要求が必要になる場合があります。

キャッシュ

データオブジェクトにフェッチされたデータのレコードが含まれています
キャッシュにデータを保存するための.store（）メソッドがあります
キャッシュからデータを取得するための.retrieve（）メソッドがあります
モデルとモディファイアは、保存と取得のためのアクセスを利用できます（サーバーよりも情報を共有するためのより高速な中間の場所として機能します）

発表者

ビューからフォーマットされたデータのリクエストを処理します
モデルからのデータの要求（完了のためにコールバックを渡す）は、プレゼンテーション用のデータをフォーマットし、ビューのコールバックを呼び出します

モデル

プレゼンターからのデータの要求を処理します
キャッシュからデータを要求します（cache.retrieve（））
データがキャッシュにない場合は、サーバーに要求してからキャッシュに保存します（cache.store（））
コールバックを介して発表者に返されるデータ

修飾子

データの変更を求めるビューからのリクエストを処理します
投稿、書き込み、削除のリクエストタイプを指定する
個別に処理できる特定のタイプのリクエストのみをサポートします（設定など）
新しいデータをキャッシュに保存する（cache.store（））
データをサーバーにプッシュします
データストレージの成功についてコールバックを呼び出します

これは非常に大きなプロジェクトであり、他にも多くの作業が行われるため、最初から正しく実行することをお勧めします。

編集1

Cache.store（）メソッドとcache.retrieve（）メソッドはどちらも、キャッシュ内のデータを参照するために必要な情報のみを受け取り、データの保存方法は指定しません。キャッシュメソッドはこの情報を使用して正しいデータに応答または保存しますが、データが保存される内部構造は秘密にされます。

Erik Reppen · Answer

さて、あなたはあなたが行くにつれて編集しているので、私が現在見ているものを見ていきましょう：

そのため、ユーザーはコンボボックスで何かを選択して動作をトリガーし、接続されている別のコンボの内容を入力します。

ビューは、データのIDと、コンテンツを更新する必要があるコンボを識別する何かを使用してプレゼンターにデータを要求します。これにより、プレゼンターは、フォーマットされたデータを適切なオブジェクトに渡すようにコールバックを設定できるように、誰が要求しているかを知ることができます。

プレゼンターは、データのIDとそのデータをフォーマットするためのコールバックを使用して、モデルにデータを要求します。

モデルは、データのIDを使用してキャッシュからデータを要求します。すでに持っているデータをすぐに返すか、データのIDを持つ修飾子にデータを要求します。最終的にそのデータを取得し、そのデータを引数としてコールバックを起動します。これにより、最終的にデータがフォーマットされ、必要なウィジェットに渡されます。

私にとっての大きな質問...実際に何かが起こる前に、なぜ同じ引数を3〜4回渡すのですか？それはあなたにとって悪臭がするはずです。ひどい。カリー化されていないタイプのシナリオで同じ引数を2回渡すときはいつでも、気まぐれを取る必要があります。 2つのオブジェクトが同じ引数に作用する必要がある場合、それらは別のオブジェクトのコンポーネントとして存在する必要があります。

コンボビュー以外の誰かが、フォーマットされたデータを必要とする他のコンボを知る必要があるのはなぜですか？なぜビューのデータをフォーマットするために、コンボビューの外にあるものを知っている必要があるのですか？最終的にデータを取得するために、複数の最上位オブジェクトにIDを渡す必要があるのはなぜですか？

前に言ったように：

私はあなたが本当に必要とせずにサブドメインを分割していると思います。

モデルは、その中にキャッシュと修飾子があるので意味があります。これら2つの動作の詳細に煩わされる必要はありません。また、その一般的なモデルオブジェクトは、モデルコンポーネントが新しい構造を実装して作成するために必要なすべてのデータを含む、新しいタイプのデータテンプレートを追加するための便利なメソッドを持つのに適した場所です。アクセス可能/バインド可能。

Presenterは間違いなくあなたの見解のサブドメインです。データをビュー形式に変換することは、ビューの主要な責任の1つです。移植性の観点から、これは常に、他の方法でHTMLとやり取りしているものと一緒に移動する必要があるため、HTMLを分離してもあまり意味がありません。

最高レベルでは、これら3つは、重要なUIアプリで分離する価値のある常緑の懸念事項と見なされる傾向があります。もちろん、特定のアーキテクチャ用に分離したいものは他にもたくさんあります。非常に再利用可能なクライアント側のアーキテクチャ/フレームワークについて話している場合、これら3つはいくぶん重要だと思います。

Data-structure/server-communication-最近買収/合併した会社の別の同様のアプリでホワイトラベルっぽい変身をしたいとし、リクエスト以外のすべてを台無しにすることができると想像してください最終的には、コードが完全な災害であり、今のところ手つかずになっている新しいサーバーからデータを更新して取得します。ここで、データを更新、バインド、および取得するための汎用インターフェイスが必要になります。このインターフェイスは、データが実際に構造化され、サーバーとの間で送受信される方法から切り離されています。 Ajaxが実行していることは何でも、データが配信および送信され、エントリポイントを確認することで、Ajaxとのやり取りは、元のアプリのデータとやり取りする場合と同じように、新しいアプリのコンボボックスUIアプリロジックでも機能します。あなたの場合、私はおそらく、新しいデータを正規化して、エントリの時点で古いデータのように見せ、次にajaxの相互作用の時点で適応させて、古いキャッシュロジックを使い続けることができるようにします。
I App Logic-これはDOMとHTMLのものを埋めるレイヤーです。最小限のクライアント側の専門知識を持つサーバー側の開発者は、これを使用してウィジェットを実装する方法を理解できるはずです。基本的にコントローラーですが、UIレイヤーからプレーンな英語の非UI開発者フレンドリーでないDOMに依存しないイベントがトリガーされる別のイベントドリブンレイヤーとして実装することをお勧めします。 /フードの下に何を重ねても。ここでは、comboObject.newChoice( handler );のようなリスナーを設定します。これにより、サーバー側からの粗悪なピンチヒットが必要に応じて基本的な実装を処理できるようになり、データと環境の問題を明確に分離できます。新しいタイプの機能を追加する場合を除いて、一度変更したら変更する必要はなく、自己文書化コードをここに記述するのは比較的簡単です。
Iビューロジック-コンボボックスをキャンバスまたはHTMLで構築していますか？これは、新しい環境で再利用するためにアプリ内の他のすべてを保持するために交換するものです。たとえば、レイアウトが大幅に異なるが同じビジネスを提供する既存のデスクトップ指向サイトのタブレットモバイルアプリバージョンを作成したい場合などです。懸念。 HTMLのデータをフォーマットしたり、DOMからUIアプリのロジックレイヤーにデイジーチェーン接続するためのイベントを設定したりするものはすべてここにあります。 DOM以外の問題でイベントシステムを使用している場合を除いて、jQueryはどこにも表示されません。ここに、データ構造をHTML形式のリストやテーブルに一般的に変換したり、データの変更をウィジェットの動作にバインドしたりする便利なメソッドのためにデータをラップする、一般的なPresenterのようなオブジェクトラッパーを含めることは理にかなっています。

Bart van Ingen Schenau · Answer

私の意見では、デザインにはいくつかの欠陥があります。

modelとmodifierはどちらも、データが内部的にどのように構造化されているかを知る必要があります。これにより、コードや責任が重複する可能性があります。

<更新>
たとえば、Customerオブジェクトがあり、Accountを保持できます。ここで、モデルは顧客とアカウントがどのように関連しているかを知る必要があるため、正しい情報を取得できます。データベースから。ただし、modifierは、データの更新を実行できるように同じ知識を持っている必要があります。 Customerごとに複数のAccountsを許可する変更がある場合、この変更を適用する必要がある場所が2つあります。これは私が言及している種類の重複です。
</ update>
cacheとの相互作用をより透過的にしたでしょう。

全体として、私はアーキテクチャに次の変更を加えます。

modifierは、cacheとデータベースの代わりにmodelに変更を加えます。 modifierには、MVCパターンのコントローラーと同じ責任があります。それに応じて修飾子の名前を変更することを検討してください。
cacheをcachedDatabaseに置き換えます。これは、データベース接続を処理し、結果をキャッシュして、データが2回目に要求されたときに高速アクセスできるようにします。 modelの場合、データがどこから来たか（キャッシュまたはデータベース）は透過的である必要があります。