2

私は監視アプリを構築しています。いくつかのカテゴリがあり、各カテゴリには複数のモニターがあります。モニターの例は、CPU 使用率のグラフです。

私の質問は建築についてです。プロジェクトの将来の拡張を簡単にするために MVC を実装しようとしていますが、ジレンマに陥っています。どちらか私

  1. モニターごとに個別のコントローラーとモデルを用意する、または
  2. 1 つのMonitorControllerオブジェクトと 1 つのMonitorModelオブジェクトを持ち、モニターごとに 1 つのメソッドを持つ

＃1の欠点は、

  • 各ルートを個別に定義する必要があります
  • ルートごとに異なるコントローラーをインスタンス化しますが、各コントローラーには基本的に実行するタスクが 1 つしかなく、モデルのgetData()メソッドを呼び出します。基本的に、これまでのところ、/{category}/{monitor}すべてのモニターに 1 つのルートを使用できましたが、そのシンプルさは素晴らしいものです。

＃2の欠点は

  • 柔軟性がない
  • MonitorModel各チャートのgetData()メソッドは数十行にわたる非常に複雑になる可能性があるため、オブジェクトは巨大になり、維持できなくなります。

ここで正しいアプローチは何ですか？

（ちなみに、私はPHPを使用しています。）

4

1 に答える 1

1

モデルの第一のルールは、モデルをできるだけ単純にすることです。その数十行のロジックを別のプロジェクトに入れ、それを mvc プロジェクトで参照します。MVC アプリケーションを UI と考えてください。すべての「ビジネス ロジック」は、最終的にどのように表示されるかを完全に認識できないプロジェクトに保持する必要があります。

これを行うと、おそらくメソッドを備えたMonitorsコントローラーが必要であることがかなり明確になりますData。これは、表示するモニターの指定子を取り、そのモニターのビューを生成します。それが最も直接的なMVCの方法です。

多種多様なモニターに対応！DisplayTemplatesさまざまなタイプのそれぞれを表示するハンドルのスイートが最適です。あなたの見解はData本質的に になり@Html.DisplayFor(x => x)ます。 を使用する際の必須の msdn リンクDisplayTemplates。

注意として、常に単純な DTO をビューに渡します。シンプルであればあるほど、長期的には生活が楽になります。

これで、物事が変化しても、さまざまな部分が互いにあまり踏みにじられない、きれいにスライスされた素敵なアプリケーションができあがります。

于 2013-02-27T20:34:22.237 に答える