ビューがモデル レイヤーの状態を変更するためにコントローラーによって使用されたサービスがわからない場合は、モデルを監視する現在のビューで従来の MVC (またはそれに近いもの) を実装するのが最善の方法です。その場合、使用される各サービスは、コントローラーによって処理されたときにビューに通知します。その場合、以下の内容は適用されません。
悪い考え..
ビューとコントローラーは、サービスの初期化を担当するファクトリを共有する必要があります。これは、コントローラが特定のサービスを使用した場合、すでに初期化されているサービスについてこのファクトリにクエリを実行する機能を追加できることを意味します。
if ( $this->serviceFactory->hasCached('recongnition') )
しかし、それは必要ではなく、私見ですが、それは本当に有害なことです。ファクトリを UI ロジックの重要な部分にする必要があります。
注:この場合のファクトリは、グローバル状態に依存せずに、各サービスが 1 回だけ作成されるように強制します。
異なるアプローチ/視点
何らかの理由で、すべてのビューが全知でなければならないという前提から始めます。それが現在の混乱の原因です。
すべてについてすべてを知る代わりに、2 つの架空のサービス:
Accounting
: 請求書の処理
Library
:文書管理用
現在のドキュメントを一覧表示しているページを見ているとき、Accounting
サービスにエラー状態があることをビューが気にするのはなぜでしょうか? 実際にそのエラー状態をどのように達成しますか?
これらのサービスのエラー状態は、「ログイン ページ」の外観に影響しますか?
そう。ここでの要点は次のとおりです。コントローラーが何かを実行して、モデルレイヤーのどこかでエラー状態が発生した場合でも、ビューはその特定のサービスが必要な場合にのみ、それについてのみ知る必要があります。
注:
もちろん、Web アプリケーションではビューとコントローラーがペアになる傾向があるため (「ドキュメント リスト」を処理するためのコントローラーがあれば、対応するビューも存在する可能性があります)、コントローラーが使用されることは非常にまれです。現在のビューが認識していないサービス...私は実際にそのような発生のユースケースを考えることはできません.
PS
実際には、モデル層の状態はサービス自体ではなく、サービスが操作するドメイン オブジェクトに保持されます。
各サービスが一度だけ初期化されることを確認できる共有ファクトリを使用する場合、そのビューが使用するサービスは同じになります。また、サービスが機能するドメイン オブジェクトがまだそこにある可能性があることも意味します (もちろん、実装によって異なります)。
たとえば、既に存在する電子メールを使用してユーザー アカウントを作成しようとすると、ストレージの抽象化がUNIQUE
制約違反に関する例外を取得すると、アカウントの詳細を表すドメイン オブジェクトがエラー状態になります。適切な「登録失敗」ページを表示するには、データとエラー状態の両方を含むドメイン オブジェクトがサービスに必要です。
I hope it helps