APIリクエストはMVCのどこに配置すればよいですか？

MVCパターンを使用してWebアプリケーションを構築しています。この種のアーキテクチャに従うと、データベースとのやり取りに使用されるすべてのメソッドがモデルに実装されていることがわかります。

しかし、Web上で他の人に公開されているサービスを呼び出さなければならない場合はどうなりますか？たとえば、ページのフォロワーをすべて取得するためにFacebook APIにアクセスしたいので、これらのメソッドをどこに配置しますか？

このモジュールはプレゼンテーション専用であり、コントローラーを使用してデータを取得することはできませんが、モデルは通常データベースとの対話専用であるため、ビューは明らかに良いアイデアではありません。

それで、それについてのヒントを教えていただけますか？そして、MVCアーキテクチャについて間違いを犯していないかどうか教えてください。

モデルはデータベースとのやり取りに限定されず、モデルはデータの取得と操作を行います。

したがって、ビューとコントローラーにとって、データがデータベースまたはWebサービスから取得される場合、または完全にランダムである場合でも、違いはありません。したがって、モデルで実行する必要があります。

MVCはプレゼンテーションパターンであり、異なる表現レイヤーのみを分離します。

モデルがスパゲッティコードの統一された混乱である必要があることを意味しません。モデル自体も同様に階層化できますが、コントローラーはデータの出所を知る必要はありません。

モデルのパブリックメソッドは、次のように構造化できます（擬似コード）。これは、コントローラーによって呼び出すことができます。

public MyDataClass getData(int id) {
    WebServiceData wsData = WebService->getData(id);
    DatabaseData dbData = ORM->getData(id);
    return new MyDataClass(wsData, dbData);
}

WebServiceまたORM、依存性注入を介してモックに置き換えることができるインターフェイスのインスタンスである必要がありますが、テストのためにコントローラーとビューを変更する必要はありません。

M、V、Cが何であるかについて、一般的な（意図的な？）誤解があります。ではない彼らは取るが、何の役割についてです、彼らは。

MVCの元のデスクトップGUI定義では、それらはモジュールでした。通常、アプリケーションにはそれらのいくつかがあり、場合によってはトリプレットで動作し、場合によっては少数のコントローラーが混合および適合できるさまざまなビューやモデルがあります。

Webフレームワーク、OTOHでは、それらはレイヤーとして見られる傾向があり、それぞれが1つだけであり、主にいくつかの下位の抽象化レベルをカバーすることを扱います：「モデルレイヤーはデータベースを抽象化」、「ビューレイヤーはプレゼンテーションを実装」、レイヤーはユーザー入力を処理します」。

そのため、データベースとの対話専用のモデルが既にあり、ソースAPIを処理するために別のモデルを作成する必要があると思います。それらを可能な限り類似させると、ほとんどのコントローラーとビューのコードはどちらのモデルでもシームレスに機能します。

MVCの議論の難しさの一部は、異なるグループが異なることを意味するためにそれを採用したことです。たとえば、Railsアプリで使用されるMVCの実装は、Swingアプリを書いている人にはほとんど認識できません。MVCがまだ明確に定義されているものである限り、それは一連のガイド原則（コアアプリケーションを視覚的表現から分離し、柔軟なメカニズムを提供して2つを一緒に組み込むことができます）であり、さまざまな方法で実装できます方法。

確かに、異なるMVC派生デザインに異なる名前を付ける傾向があります（これについての議論についてはMartin Fowlerによるこの記事を参照してください）、または正確な命名をあきらめることさえあります-たとえば、AngularJSはModel-View-Whateverとして説明しますフレームワーク。

そのため、使用している「MVC」のバージョンを知らずに答えることは困難です。ただし、APIリクエストは通常​​、コアアプリケーションの一部（別の視覚的表現を使用する場合に変更すべきではない部分）であり、多くの実装では完全にモデル内に含まれます。

ここで、モデルは次のように説明されます。

モデルには、コントローラーに取得され、ビューに表示されるデータが保存されます。データに変更があるたびに、コントローラーによって更新されます。

コントローラーには、サービスを呼び出すロジックが含まれているか、別のServiceオブジェクトを呼び出していると思います。サービスが分離されている場合は、より簡単にテストを作成できます。たとえば、ネットワークを介したサービスへの接続が不可能な場合、一部TestServiceはServiceローカルからの応答を提供できます。

また、コントローラーがサービスを呼び出すことを示唆するこの回答を確認してください。

モデルには実際のコードを含めることはできません。また、コントローラーによって操作され、ビューによって表示されるコンテンツを管理するために使用される、より多くのメッセージまたは構造体として表示される必要があります。

コントローラーは、API、データベース、サービスなどと連絡を取り、変更を要求し、モデルの必要な更新を管理する必要があります。

MVCパターンの全体的な強みは、ロジック（コントローラー）をビューと状態（モデル）から切り離すことです。そうすることで、ビューとモデルが単に変更を許可されないため、コントローラーのコードのみが副作用を作成できることが保証されます。

また、モデルをさまざまなコントローラーとビューの間で共有できるため、コードの再利用が改善されます。

ここからは少し外れているかもしれませんが、多くの場合、これがWebAppsと[複雑な]リモートAPIの操作について私が感じる方法です。

モデル（つまり、データ軽減関数のスタック）ではなく、クラス（つまり、データ軽減メソッドのライブラリ）にします。それはより透明で、よりロジック/スキーマにとらわれないように見え、ロードすることなくどこでも使用できます->使用するたびにモデル/コントローラ自体を呼び出します。ロジックはまだ分離されており、データポイントは依然として柔軟性があり、クライアントAJAX-> appJSON-> appLIB-> remoteAPI-> remoteJSONなどをスタックしてエンドポイントを間接的にポーリングするなどの奇妙なケースでは、相互運用性がよりオープンになっているようです。