さまざまなページにグラフを表示する必要がある Web アプリケーションに取り組んでいます。各ページは Controller に対応し、グラフを必要とする各 Controller には ChartService へのインターフェースがあります。このサービスは、サード パーティ ベンダーにグラフを要求します。次に、JavaScript を使用して HTML にラップされた画像を文字列として出力ストリームに直接返します。ChartService には、データと、期間やテンプレート ファイルなどのその他のパラメーターを指定する必要があります。
独自のコントローラーに抽象化されたグラフ作成機能を使用する必要がありますか? ChartController の異なるアクション メソッドによって、さまざまな種類のグラフを提供できます。
しかし、複数のコントローラーからページの一部を提供していると問題になるでしょうか? 機能に独自のコントローラーを与える必要がある場合を決定するためのガイドラインは何ですか?
何も変更する必要はないようです。コントローラーがその特定のサービスに直接依存しないように、ラッパー内でサードパーティのサービスを抽象化しました。この場合、新しいコントローラーを作成すると、ラッパーの周りにラッパーを作成することになります。
アプリケーションに動作を追加する場合は、新しいコントローラーを作成します。
IMO、URLのような「チャート」セクションがある場合
charts/income
charts/expenditure
その場合、チャーティング コントローラーが理にかなっています。また、たとえば、チャート コントローラーがさまざまなページからの ajax クエリによって排他的に呼び出される場合でも、chartingController は意味があります。しかし、次のような URL を使用する場合
products/list
products/yearlyStockChart
employees/details
employees/performanceChart
次に、List() および yearlyStockChart() アクションを含む ProductsController と、details() および performanceChart() アクションを含む employeesController が必要で、両方のコントローラーが chartingService を利用します。
デイブ、
メインコントローラーが継承した抽象ベースコントローラーが必要です。ベースコントローラーには、必要なすべての機能があり、子コントローラーが適切な部分をオーバーライドします。あなたのジレマの完全なコンテキストを知らなくても、これは実行可能な（または望ましい）アプローチである場合とそうでない場合がありますが、現在、すべてのコントローラーで採用しているアプローチです。
[編集] - このアプローチの優れた点は、運が良ければ、basecontroller の機能の 75% が残り、関数の 25% のみがオーバーライドされたり、その子コントローラーに追加された機能が追加されたりすることです。これにより、新しいチャート タイプごとに、同一のアクション メソッド名を持つ可能性のある独自のモデル/コントローラーが存在するため、非常にクリーンなパラダイムが得られます。したがって、新しいチャート タイプの「エントリ」のコストが非常に安価になります。
ジム