0

PHP MVC フレームワーク (Yii、しかし私の質問はほとんどの MVC フレームワークに当てはまる可能性があります) を使用して、Web アプリケーション (Web サイト) と RESTful Web サービスを含むプロジェクトを作成しています。アプリケーションとサービス ロジックを論理的に分離する方法について、初期の設計上の決定に直面しています。ここにいくつかの真実があります：

  • Web アプリと Web サービスは多くの機能を共有し、表示される形式 ( Viewvs JSON) のみが異なります...
  • ...しかし、Web アプリと Web サービスには独自の機能がいくつかあります (つまり、Web アプリにはできてサービスにはできないことがあり、その逆もあります)。

ここに私の願いがあります：

  • 共通機能の実装を可能な限り共有したいと思います
  • ControllerWeb サービスと Web アプリケーションのロジックを組み合わせた結果、 が扱いにくくなりたくない
  • Webサービスと Web アプリのコントローラーを別々に作成することに少し嫌悪感を覚えるAction
  • 本当に必要な設計上の決定でない限り、Web サイトで Web サービスを使用したくありません。データベース インターフェイスを使用する多くの組み込み機能を利用できなくなりますIDataSource。また、Web サービスに接続して、利用可能なインターフェイスやその他のインターフェイスに準拠するクラスを作成する必要があります。また、パフォーマンスがわずかに低下する可能性があります。

私はそれについて少し考えて、以下のいくつかの解決策を考え出しました. これらのどれが私の欲求を満たすと思うか、または私の欲求が合理的でない/非生産的でないかどうか教えてください.

  1. との完全に別個のコントローラーを実装しますWebApp(WebServiceコードを共有しないように 2 つをモジュール化します)。
  2. WebAppとに別々のコントローラーを実装しますが、面倒なWebService作業を行うメソッドを作成し、それらのメソッドを呼び出して実装を共有しitem/findBySomeCrazyCriteriaます。FindItemsBySomeCrazyCriteriaFunction()他の場所。
  3. Web アプリで Web サービスを使用するようにします (サービスの計画された機能を拡張する必要があります)。
  4. WebAppとの両方に 1 つのコントローラーを実装します。これは、 $this->getModel()` の観点からタイプのものの汎用フックを含むWebServiceから拡張され、必要に応じてオーバーライドを使用しますBaseControllerREST
  5. 他に何か

私の質問は Yii に関するものですが、これは多くの開発者にとって過去に発生したに違いないと思います。あなたが何をしたか、前進するために何を勧めるか知りたいです。間違ったアプローチを選択すると、「MVC が壊れる」か、後で後悔するのではないかと心配しています。

4

2 に答える 2

1

注：「MVCの破損」について心配する必要はありません。Yiiを使用することを選択したので、その部分はすでに発生しています。

問題の根本は、コントローラーが多くのことを実行する（したがって、SRPに違反する）という事実にあります。「コントローラー」と呼ばれるものには、実際にはアプリケーションロジック（モデルレイヤーの一部である必要があります）とUIロジック（通常はビューインスタンスの一部である）も含まれています。

必要なのは、1つのモデルレイヤーと2つのプレゼンテーション（「Webアプリケーション」と「Webサービス」と呼ばれるもの）を備えた単一のアプリケーションです。コントローラーは少し可能である必要があります。

アプリケーションロジックをサービス層に移動する必要があります。サービス層を介して、プレゼンテーション層がモデルと対話します。あなたははるかに軽いコントローラーになってしまうでしょう。次に、コードの重複がないか、わずかな重複がなくても、プロジェクトに必要なプレゼンテーションごとに個別のコントローラー/ビューのセットを提供できます。

于 2013-01-07T06:28:39.627 に答える
0

複数のコントローラーを作成しないことをお勧めします。コントローラーではなく、モデル内にドメイン ロジックを保持する方がはるかに優れたオプションです。コントローラーはロジックへのゲートウェイとしてのみ機能し、クライアントが要求する形式でそれらを提供する必要があります。JSON エンコードされた応答として、またはビューを介して。クライアントの要件を特定し、モデルから結果を取得した後、応答を適切な形式に変換するタスクだけを維持するのが最善です。

このフローは、適切なヘルパーと適切に実装されたルーティング サブシステムを使用して合理化できるため、クライアントの要件を簡単に検出できます。

例えば。asが JSON 応答/user/subscriptions.htmlをフェッチする HTML ページをフェッチします。/user/subscriptions.json

于 2013-01-07T04:35:11.090 に答える