生成ロジックをMVC構造体に入れるべきですか？

Question

モデルビューコントローラのセットアップを使用するプロジェクトがあります。

このプロジェクトの一部は、複数のモデルにわたってクエリを必要とするかなり複雑なレポートを生成することです。

私は現在、ユーザーからのリクエストを処理し、どのレポートをレンダリングするか、どのパラメータを使用するかを決めるレポートコントローラを持っています...残念なことに、このコントローラもまた、レポート生成コードもすべて含めるようになっています。私はこのコードが概念的にレポートコントローラ（ビジネスロジック、ルーティングコードではない）に属していないと確信していますが、明らかに特定のモデルに属していません。

OO設計の面では、このビジネスロジック型コードは実際にどこに存在するのでしょうか？

（答えがより明確になる場合は、これはCakePHPフレームワークを使用したPHPプロジェクトです）。

Answer 1

MVCは、ユーザー操作を処理するためのコアパターンと考えることができます。 MVCの視点からアプリが解決しようとしているすべての問題を見ているべきではありません。

レポート生成が重要な部分の場合は、ReportGeneratorクラスのようなものはありませんか？詳細に応じて、別々のプロセスとしてレポート生成を行うことも役立つことがあります。

Answer 2

私は概念的な答えと実用的なアドバイスを提供することができます。

ここに概念的な答えがあります。コンピューターモニターとプリンターは同じ目的の2つの異なるマシンと考えてください。彼らの共通の仕事は、テキストとグラフィックを表示またはレンダリングすることです。両方ともモデルオブジェクトにビューを提示します。コンピュータモニタの場合、オブジェクトはスクリーンに表示されます。プリンタの場合、オブジェクトは紙に描画されます。

概念的には、レポートは画面またはプリンタのいずれかにレンダリングできます。情報がどこに向けられているのかということだけです。モニタに指示された場合、GUIフレームワークはOSウィンドウマネージャと対話してビューを作成します。情報がプリンタに送信される場合、レポートジェネレータはOSおよびプリンタドライバと対話してハードコピーを作成します。

このようなデザインでは、ビュークラスの2つの階層を使用したり、ビュークラスにプラグインするストラテジパターンを使用したり、デザイン全体が他のものになることがあります。レポートのコントローラオブジェクトは、レンダリングされるデータの取得と整理を担当します。

これは概念的な答えです。実際には、私はそれが決してそのように見たことはありません。過去20年間に私が協力してきた会社はすべて、既製のレポートジェネレータパッケージを購入しています。次に、アプリケーションにReportGeneratorのようなクラスを作成し、それを商用レポートソフトウェアのインターフェイスとして使用します。レポートソフトウェアは、レポートテンプレートの書式設定と読み込みと保存を処理します。このようなソフトウェアには通常、素敵なGUIエディタやデザインレポートが含まれています。レポートジェネレータには、レポートテンプレート、データ、およびプリンタの名前を渡します。それから、レポートを作成して印刷するという魔法を働かせます。

場合によっては、レポートを表示する代わりに、レポートを表示する必要があります。その場合、私はまだレポートジェネレータを使用しますが、レポートのPDFファイルを作成するように指示します。次に、WebブラウザまたはAdobe Readerを使用して、画面上のレポートを表示します。

おもちゃのプロジェクトやプロトタイプ以外は、レポートを生成することを目的としたソフトウェアパッケージを調べることをおすすめします。真剣に。