1

以前、私はこの質問をしました: should-i-create-an-object-or-work-with-an-array

私は今、私が取り組んでいた概念を超えて考えようとしています. あなたの考えを私と共有してください。これをGETしたい。

MVC をデータ マッパーと組み合わせてセットアップする場合、たとえばフォーラムの場合、これは論理的でしょうか。

重要なものはすべてエンティティです。投稿、スレッド、ユーザー、フォーラム。基本的に、コントローラーはページと見なされます。さまざまなテンプレート (リストやフォームなど) を表示することを選択できますが、それは多かれ少なかれページです。

ルーターを介して必要なコントローラーをロードし、データを取得してテンプレートに表示します。

スレッド内のすべての投稿を表示するために、これはどのように機能しますか。

ルートはスレッドに設定されます->スレッドコントローラーをロードします->コントローラーはエンティティ（投稿、ユーザー）に情報を要求します->エンティティはマッパーに必要なものを伝えます->マッパーはデータベースからそれを取得し、エンティティに返します->エンティティは情報を返しますコントローラ -> コントローラはビ​​ュー -> ビュー表示に情報を返します。

それは正しい考えですか？

「モデル」は MVC からどこへ行ったのでしょうか。または、手順がありませんか？

サードパーティのツールは使いたくありません。すべてを理解するためにゼロから構築したいと考えています。

これを正しく開始するにはどうすればよいですか？

4

1 に答える 1

-1

私は、ページをコントローラー (レンダリング前に必要なロジック) とビュー (ページの外観を決定する) の合計と見なす傾向があります。一般に、まだ完全に理解していない設計パターンに取り組むことになるため、最初に独自のものを作成しないことをお勧めします。人気のある PHP フレームワークを選んで実装方法を確認し、それでもよろしければ独自のフレームワークを作成してみるのがよいと思います。私の見解では、これらすべてをコーディングするのは大変な作業です。特に、ORM も書きたい場合はなおさらです。

スタック オーバーフローに関するフレームワークの推奨事項には敬遠していますが、ここでのコメントから、Symfony2 がこの設計パターンの最良の実装の 1 つであると考えられていることがわかります。特に、依存性注入を使用しているためです。「mvc」タグを付けた質問もいくつか読んでください。たくさんの質問があります。価値のあることとして、私はデザイン パターン (つまり、フレームワーク X がパターン Y を実装するかどうか) にあまりこだわることはありません。アプリケーションがモジュール化され、簡単にテストできる限り、それは大きなメリットです。

于 2013-06-01T13:58:40.883 に答える