2009-06-04 22 views
15

私が取り組んでいるいくつかのプロジェクトでは、私自身の手作業によるPHP MVCフレームワークがあります。最初にフレームワークを作成したとき、それは管理CMSを構築するというコンテキストの中でした。したがって、モデル、ビュー、コントローラの間には非常に良い1対1の関係がありました。 DBには単一の行があり、単一のモデルにマッピングされます。コントローラはモデルをロードし、レンダリングするビュー(編集フォームなど)に渡します。ニース、クリーン、そして簡単。MVCコントローラからPHPでのビューへのデータの受け渡し

しかし、私はサイトのフロントエンドで作業しているので、物事は固執しています。ページは必ずしも単一のモデルのビューではありません。これは、20人のユーザー(各ユーザーモデル)を持つユーザーディレクトリリストです。さらに、ページ付け(現在のページ、合計ページ、結果の数)および/または検索クエリなど、リクエストに関するメタデータが存在する可能性があります。

私の質問は、このデータをすべてビューに渡す最もクリーンな方法は何ですか。私が検討している

いくつかのオプション:

  • コントローラは、配列を作成し、単一のパラメータとしてビューにそれを渡すことがあります:

    class UserController{ 
    
        public function renderView(){ 
    
         // assume there's some logic to create models, get pagination, etc. 
         $data = array() 
         $data['models'] = $models; 
         $data['currentPage'] = $current; 
         $data['totalPages'] = $total; 
         return $view->render($data); 
        } 
    } 
    
    class UserView{ 
        public function render($data){ 
         // render the data 
        } 
    } 
    
  • はでプロパティを作成します。コントローラーにそれらを設定させる:

    class UserView{ 
        public $models; 
        public $currentPage; 
        public $totalPages; 
    } 
    
    class UserController{ 
    
        public function renderView(){ 
    
         // assume there's some logic to create models, get pagination, etc. 
         $view = new UserView(); 
         $view->models = $models; 
         $view->currentPage = $current; 
         $view->totalPages = $total; 
         return $view->render(); 
        } 
    } 
    
  • 任意の数と名前のデータを保持できるコンテナとして、一般的なHashMapまたはCollectionオブジェクトを表示することができます。

    class UserView{ 
        public $collection = new Collection(); // works like a Java collection 
    } 
    
    class UserController{ 
    
        public function renderView(){ 
    
         // assume there's some logic to create models, get pagination, etc. 
         $view = new UserView(); 
         $view->collection->add($models,'models'); 
         $view->collection->add($currentPage,'currentPage');   
         return $view->render(); 
        } 
    } 
    

は、私は技術的にどのでし仕事のが、私は最良の選択が不明だということを知っている、または私が欠けている、より良い以上の従来の選択肢があるかどう。

答えて

3

私は(...あなたが好む場合や、Fat Models Thin ControllersFat Models, Skinny Controllersの概念をお勧めするつもりです

、あなたのモデルが厳しすぎる - RowDataGatewayのようなだけで何かを表現するために、あなたのモデルを結ぶ非常にあります制限する。

実際、良いモデルは、あなたがデータベースからデータをまったく読み込んでいるという事実を隠していると思います。実際には、あなたのデータはテキストファイルやWebサービスなどにある可能性があります。あなたのモデルを賞賛されたDBALのように扱うなら、 "データはデータベースから来ている"という考え方から逃れることはできません。

+1

おかしい、私はこの質問を投稿する前に、脂肪モデルに関するJamis Buckの記事を読んだが、私はその概念をグーグルで調べることは、そのような豊富なリソースをコンセプトに戻すことは理解していなかった。自分の小さな哲学だと思った。先端に感謝します。 –

+0

良い記事:-)私は完全に脂肪モデルのアイデアに同意するのか分からない。モデルは単なるモデルでなければならないと思います(単数形で)。つまり、FindPeople()のようなメソッドは適合しません。私はしかし、完全に皮肉なコントローラの利点に同意します。サービスレイヤーの引数を入力します。今私はこれについて多くのことを知らず、専門家ではないと主張しますが、私はその価値があると思います。 はい、新しいレイヤの複雑さが増しますが、コントローラはPeopleService :: FindPeople()などを呼び出すことができます –

+0

モデル自体は多層化することができます。いくつかのすぐに使用できるフレームワークには、すでに多層モデルが用意されています。 Symfonyには、DBALとORMの両方が付属しています。これは、propelタスクで足場を張っています。 ZFはテーブルと行のゲートウェイを提供し、ドメインモデルを適用するために私たちに任せます。 Bill Karwinの記事をhttp://karwin.blogspot.com/2008/05/activerecord-does-not-suck.htmlで読んでみることをお勧めします。 –

0

私は、人気のあるMVC /テンプレートフレームワークで実装された最初の2つの方法の両方を見てきました。

djangoは、ビューにテンプレートを埋めるために使用する変数の辞書を渡して最初のメソッドを使用します。

smartyは、Smartyオブジェクトを作成し、コンテナ内の各プロパティに値を割り当てる2番目の方法を使用します。

3つ目の方法は、基本的に2番目の方法と同じであるように見えますが、アーキテクチャの違いはわずかです。

本当に、あなたがまだ考えていないことは言わなかったと思います。基本的に、これらのアイデアはすべて聞こえるので、あなたが最も気楽に感じるものを実装してください。言い換えれば

0

私が使用しているものでは、ビューのメソッドとプロパティにアクセスできるように、自動的にコントローラにビュープロパティがあります。すべてのパブリックプロパティは、ビューが '$ this'ビュービュー内でアクセスできるようになります。これは、ビューが自身のオブジェクトコンテキスト内でレンダリングされるためです。

$this->view->myVar = 'test'; 

とビューで:コントローラで

$this->myVar; // 'test' 

ザは、同じビュー・オブジェクトの両方の別個のインスタンスであるので、同一のレイアウトのために行く:

$this->layout->myVar = 'test'; 

レイアウト内:

$this->myVar; // 'test' 

フレームワークは以前は専有であったが、一般に公開される予定である。あなたがそれが助けになると思うなら、私はあなたにそれからいくつかのコードを送ってうれしいです。覚えておいて、最も簡単な答えは通常最も良い答えです。

+0

これは、私が2番目の例で考えていることです。私はコード例を単純なものにしていましたので、私のコントローラが実際にビューのインスタンスを持っているので、あなたが提案したとおりに正確に動作します。私はこのオプションについて不快な点は、同じモデルの5つのビューをレンダリングできる1つのViewクラスがあることです。各ビューには独自のデータ要件があります。つまり、Viewクラスには多数のプロパティがあり、そのうちのほんの一部だけがどのビューにも関連します。それは私が望むよりも清潔です。 提案がありますか? –

+0

上記の例では、レイアウトとビューが別々のインスタンスであることに気付きました。ビューをシングルトンにするのではなく、複数のビュー・オブジェクトを作成できるようにすることができます。つまり、ビューはレイアウトとは異なるインスタンスであり、それぞれに設定するプロパティは互いに独立しています。 複数のインスタンスを持つことができるので、異なるヘルパーパスやビューパスなどを持つこともできます。そのため、特定のヘルパーはプロパティと同じように特定のビューでのみ使用できます。論理的な構成だけでなく必要に応じて、より高度なカスタマイズが可能です。 – Tres

+0

あまりにもずっと前にそれをリリースhttp://europaphp.org/ – Tres

関連する問題