テンプレートには { } だけのロジックを含めるべきではなく、すべての部分を含めてブロックする必要があると私は確信しています。MVC フレームワークでは、V は通常、生の php と HTML が混在しています。これは、HTML をきれいにするのに慣れている人にとっては非常に悪い IMO であり、デザイナーにとっては悪夢です。しかし、コントローラー内にビューロジックを配置することも間違ったアプローチです。
このような作り方を教えていただきたいです。リクエスト -> コントローラー -> モデルの読み込み... ロジックはすべてを送信 -> ビュー -> ロジック ブロックの表示... -> テンプレート
これは Laravel や Fuelphhp のようなフレームワークで可能ですか? または、より一般的には、これは良い習慣ですか？
ビューは、プレゼンテーション ロジックを担当する MVC の一部です。適切に記述されたビューは、モデル レイヤーから情報を取得し、この情報に基づいて、ユーザーが受け取るべき応答を決定します。
ビューが HTML 応答の作成を担当している場合、複数のテンプレート (アーカイブ バージョン: https://archive.md/CiHhD ) を組み合わせて作成します。または、HTTP ヘッダーをブラウザーに送り返すだけかもしれません。
別の状況では、ビューは REST API 用の JSON または SOAP 用の XML を生成するだけかもしれません。
しかし、これらすべての場合において、view は情報をどのように表現するかを決定します。コントローラーは、モデル レイヤーと現在のビューの状態を変更することのみを担当します。
MVC自体はデザインパターンであり、プレゼンテーション層とモデル層の2層から構成されています。モデル レイヤーはドメイン ビジネス ロジックのすべてを扱い、プレゼンテーションはユーザー インターフェイスとインタラクションを扱います。
「コントローラーレイヤー」や「ビューレイヤー」などというものはありません。
ほとんどの Rails クローンがビューをテンプレートと主張し、ORM を「モデル」と呼ぶのには単純な理由があります。これらのフレームワークは、ラピッド プロトタイピング (使い捨てコードの生成) のために作成されたものであり、保守性のためのものではありません。
非常に一般的です: 多くの PHP フレームワークは「ビュー」をあまりうまく実装していません。ビューがテンプレート ファイルのみである必要がある、またはビューがテンプレートである必要があるということは何もありません。ビューは、モデル データを視覚化するコードです。それは、必要に応じて複雑にすることも単純にすることもできます。JSON やバイナリ データなどを返すクラスにすることができます。HTML を使用する必要はまったくありません。
includeHTML が関係する場合、コントローラーが基本的にすべての変数を設定し、次にHTML テンプレートを設定する必要があるということは何もありません。それは少なすぎます。ビューは、特定のデータまたはオブジェクトを視覚化するために必要なことは何でも実行する独立したコード (おそらくクラス) である必要があります。ビューは、複数のクラスで構成できます。HTML テンプレートがディスクから読み込まれる前に、ビューにロジックのレイヤー全体が存在する場合があります。アプリで最も意味のあることを行います。
上記のすべての感情に同意します...
ロジックはビューに属していません...その特定のビューに直接関連するビューロジックでない限り。いくつかの基本的なロジックを許可すると、ビューがどうあるべきかについて独自のルールを回避しようとするクラスの急増を防ぐことができます。肝心なルールは、ビューはリクエストの最後に発生し、モデルの読み取り/クエリのみを行う必要があるということです。ロジックをクラスに移動して、重複を避けます。
ビューロジックはコントローラーに属していません...主に物事を絡みやすくするため、コントローラーはモデルに変更を加えてから、ビュープロセスを呼び出します。
通常、入力を処理してモデルを変更するコントローラーレイヤーと、モデルをレンダリングするビューレイヤーに基づいて作業を整理する必要があります。
ほとんどのフレームワークと生のPHPは、この倫理を順守するために使用できます。