MVCS-モデルビューコントローラーストア

私は最近、iOS開発の学習を開始することを決めました。そのために、iOSプログラミング：The Big Nerd Ranch Guideを読みました。本の中で著者はMVCS-Model-View-Controller-Storeのデザインパターンについて説明しています。基本的な考え方は、多くのアプリケーションがデータの複数の外部ソースを利用するため、コントローラーのリクエストロジックを維持するのが非常に面倒になる可能性があるということです。すべての要求ロジックをコントローラーから別のオブジェクトに移動することを提案します。

要するに本を引用する

Model-View-Controller-Storeは要求ロジックを別のオブジェクトに入れ、このオブジェクトをストアと呼びます（図28.4）。ストアオブジェクトを使用すると、冗長なコードが最小限に抑えられ、データをフェッチして保存するコードが簡素化されます。最も重要なことは、外部ソースを処理するためのロジックを、明確で焦点の合った目標を持つ整然としたクラスに移動することです。これにより、コードが理解しやすくなり、保守とデバッグが容易になり、チームの他のプログラマーと共有できます。

そして

非同期ストアの優れた点は、多くのオブジェクトが要求を処理するために多くの作業を行っているにもかかわらず、要求とその応答のフローがコントローラーの1か所にあることです。これにより、読みやすく変更しやすいコードの利点が得られます。

私はこのパターンについてもっと知り、他の人がそれについて何を言わなければならないかを見たいと思っていましたが、オンラインで検索している間、私が見つけることができる唯一の参照はその同じ本に関するものでした（パターンはおそらく他の名前で知られていますか？）。

私にとって著者の論理は理にかなっているようで、通常のMVCパターンの論理的な拡張のように思えますが、おそらく実際にはMVCパターンの経験があまりないためです（iOS開発への進出を除いて）ソートで使用MVVのBACKBONE.JS（、であるあなたがそれMVC検討している場合））。

おそらく、より多くの経験を積んだ人が、MVCSパターンに明らかな欠陥や問題がないかどうかを明らかにすることを望んでいました。

「ストア」は、MVCSデザインパターンの場合、ストレージロジックに傾く傾向があります。iOSの場合、これは通常Core Dataの実装です。XcodeでCore Data-backedテンプレートを作成すると、このデザインパターンの「ストア」の側面がAppDelegateクラスに隠れて表示されます。

これを次のレベルに進めるために、コアデータスタックのセットアップを処理し、スタックに関連するすべてのフェッチ/保存を処理するシングルトンマネージャークラスを作成することがよくあります。引用したように、これにより、これらのメソッドを呼び出すだけでなく、必要に応じてそれらを調整することが非常に簡単になります。

ただし、「ストア」パラダイムはコアデータに限定されません。あなたのストアは単なるウェブサービスかもしれません。おそらく、Facebook、Twitter、Yelp、または他のRESTベースのAPIとやり取りするクラスがあるでしょう。これらの種類のクラスにもManagerという名前が付いていることがわかりました（同様に傾向に従っています）。彼らは、文字通りすべての内部詳細を管理しているので、他のクラスは必要なものだけを出し入れすることができます。

このデザインパターンの明らかな欠陥や問題に関する限り、他のデザインパターンと同様に、最も際立った問題は、パラダイムに沿った方法でプロジェクトをセットアップしたことを確認することです。特に新しいデザインパターンでは、これが最も難しい部分になる場合があります。「ストア」ロジックを独自のクラスに分割することの利点は、コードの保守性がはるかに簡単になるという事実です。

このコンテキストでの「ストア」は、リポジトリまたはサービスに非常によく似ています。その場合、これは非常に一般的なパターンです。 欠陥/問題は、実装と問題ドメインによって異なります。

一般的なレベルでは、本が「ストア」を使用して、ビジネスロジックのレベル+アプリケーションの一部である場合とそうでない場合があるデータのセットを処理するデータ取得ロジックのレベルを表しているようです。

たとえば、Twitter APIを「ストア」にラップすることは、そのロジックを区分化するための優れた方法です。

さらに考え
てみると、MVCのこの定義を使用すると（かなり重要だと思います）、「ストア」は実際にはモデルのサブセットです。MVCの拡張機能であるか、データ取得パターンであるかを区別することは、あまり役に立ちません。最終的には同じコードのように見えます。

結論として、あなたは彼らが示唆するアドバイスに従えば大丈夫だと思う（全体的に聞こえるようだ）。