1

MVCデザインベースのシステムのクラス、メソッド、ファイル、フォルダーの正しいレイアウトを見つけようとしています。

ページがあるとしましょう。ページは、タイトル、テキスト、サブメニューを備えたシンプルなページです。また、ギャラリー（データベースとコードの両方で別個のオブジェクトになる）を含めることもできます。

  1. 私はPageDAOすべてのデータベース関連機能を持つクラスを持っているでしょう（それはメインクラスを拡張DAOし、選択、保存、削除などの一般的なDB機能を保持します）

  2. このオブジェクトの変数と非db関連関数を定義する個別のPageクラスがあります

  3. 私はMVC自体を持っていて、PageModelページDAOクラスとページクラスを構築し、コンテンツを構築して、コントローラーで処理し、ビューの準備をします。

  4. ギャラリーはMVCの外部の別のクラス（たとえばlibsフォルダー）で定義され、ビューとして使用されることはありません（つまり、ギャラリーページ自体を呼び出すことはありません）。ページモデルはGalleryクラスを作成し、コントローラーはそれをページビューに配置します

  5. メニュークラス/関数は、より一般的な関数であり（コードがショッピングサイトなどで使用されている場合、ページとカテゴリの両方で機能するため）、別の領域で定義されます（再びlibsフォルダーになる可能性があります）。その機能に基づくメニュー設定はモデルで呼び出されます

上記は私が次の構造を持つことを意味します

  • 標準のMVCアプローチに基づくモデル、ビュー、コントローラーファイルおよびフォルダー

  • DAOすべてのクラスのdaolibフォルダー

  • 、、などPageのクラスのlibフォルダーMenuGallery

それはあなたにとって公平に見えますか？コードをあまりにも多くのクラスに分散させないようにしたいと思っています。これは、より多くの「インクルード」とより多くのオブジェクト呼び出しを意味するためです。しかし、おそらくそれが進むべき道ですか？これまでのところ、MVCアプローチをあまり使用しておらず、ファイルをかなりコンパクトに保っています。ベストプラクティスについて知りたい

4

1 に答える 1

1

ここにあなたが考えるためのいくつかの事柄があります：

  • Pageクラスは標準のドメインオブジェクトですが、PageModelクラスは実際にはモデルではありません。モデルはMVCのレイヤーです。「PageModel」と呼ばれるものは、実際にはモデルレイヤーを備えた高レベルのオブジェクトであり、ドメインのビジネスロジックを公開することなく、ビューとコントローラーが後でモデルと対話できるように、多面的なインターフェイスを作成します。私はそのような構造を「サービス」と呼んでいますが、もっと良い用語があるはずです。

  • コントローラは、ビューの「データを準備」するべきではありません。ビューはダムテンプレートではありません（または、少なくともそうではありません）。プレゼンテーションロジックを担当し、複数のテンプレートを処理できる塗りつぶしオブジェクトである必要があります。

  • HMVCからいくつかの概念を借りているようですが、MVCに触発されたパターンについて少し読む必要があります。

  • DAO、 PageModel'のインスタンスはPage' class and what you callすべてモデルレイヤーに属しています。

  • コードの断片化は、特にAPCを介してオペコードキャッシュを有効にする場合、パフォーマンスの大きな問題ではありません。しかし、時期尚早の最適化は深刻な問題です。代わりに、コードを簡単に理解できるようにすることに集中する必要があります。動作するときに最適化できます。

于 2012-07-22T15:19:14.457 に答える