PHP テンプレート エンジンはたくさんありますし、さまざまなテンプレート言語もありますが、これがどの程度のメリットになるのか私にはまったくわかりませんので、皆さんの意見を聞きたいです。
返信内容:
以前は、PHP の OO 機能はあまり優れておらず、アプリケーション ロジックと表示を分離する洗練された技術的手段がなかったため、多くのテンプレート テクノロジが開発されました。しかし、現在では、OO 機能のサポートと MVC アーキテクチャの人気のおかげで、テンプレート エンジンを (歴史的な理由を除いて) 廃棄することができます。 Zend Framework は、ネイティブ PHP スクリプトをテンプレート エンジンとして使用することを直接推奨しています。これは、PHP が本質的にコードと HTML の混合記述をサポートしており、開発者が新しいテンプレート構文を学ぶ必要がないためです。
以前は、テンプレート エンジンはあまり意味がないと思っていました。結局のところ、PHP はそれ自体でこれを非常にうまく実行できます
しかし、テンプレート エンジンである twig を見てから、私の見方は少し変わりました
これ。テンプレート エンジン 私の意見では、最大の利点はテンプレートの効率を向上できることです
簡潔な構文、よく使用されるタグ、フィルター、関数、および簡単な拡張。つまり、テンプレートを設定するときに長い PHP コードを記述する必要がなくなりました。
PHP でコーヒースクリプトも生成できれば素晴らしいでしょう。
MVC が分離されると、V がテンプレート エンジンを実行する意味がなくなり、ネイティブが最適になります。
以前は、フロントエンド開発を容易にするために主にコード分離が行われていました。
個人的にはPHPにはやはりテンプレートエンジンが必要だと思っています。
- 安全性 (デフォルトのエスケープ出力など)
- チーム内の誰かがビューに大量のロジック コードを記述しないようにするための仕様
- パフォーマンスパフォーマンスが向上すると言われています
- 読みやすいですが、個人的にはphpよりもtwigやlaravelのブレードエンジンの方が読みやすいと思います
個人的に、私は常にテンプレート エンジンに反対してきました。
主な理由は、PHP 自体がすでにテンプレート エンジンの機能を実装できるためです。つまり、PHP 自体がテンプレート エンジンです。バックエンド担当者以外による使用については、実際には少し突飛です。確かに、PHP を直接使用してテンプレートを作成すると、不規則な動作が発生しやすくなりますが、これは実際には技術的なフレームワークではなく仕様によって制限されており、ページ開発者はネイティブ コードを実行できない問題に遭遇します。バイパスされた場合でもネイティブ PHP コードが使用され、地雷を設置することができます。
このような問題を解決するには、優れた仕様、合意、レビューのメカニズムがより効果的です。 PHP 自体は非常に任意の言語であり、モジュールが行うべきではない多くのことをどこでも取得できます。 MVC は分離を目的としていますが、多くの人は依然としてモデルやビューで $_GET を読み取り、コントローラーやビューに SQL を記述します。コントローラーとモデルにhtmlを書きます。 MVC はこの種のことをまったく処理できません。そうでない場合、この MVC は汎用ではない MVC になります。
要約すると、ネイティブで解決できない問題はテンプレートでは解決できません。また、テンプレート エンジンの学習と開発のコストも増加し、デバッグが容易ではないという問題も発生します。それ自体にバグのリスクがあり、もう 1 つの依存関係を解決する必要があるなどのコストがかかります。
テンプレート デザインの意味と目的は、プログラム ロジックをページのプレゼンテーションから分離し、プログラマーとアーティストが互いに干渉することなく共同作業を容易にすることです。
しかし、初期の PHP テンプレートは、実際にはプログラマーの思考ロジックに従って作成された一連のメカニズムであり、いわゆる「ネイティブ」メカニズムを含め、ページ アーティストは依然としてそれを組み込む必要があります。プログラムロジックを表す大量の HTML が含まれています。完全な別離とは言えません。
これがどれほど重要であるかというと、以前の ASP コミュニティと比較して、PHP コミュニティは少なくとも、Web 開発のこの中心的な問題を調査し、この問題の継続的な思考と探求を促進するために懸命に取り組んできました。
Web 開発で MVC 分離を真に実装するには、プログラマーの観点から問題を考えるだけではなく、分業が明確になったら、Web 開発の作業全体の分割を考慮する必要があります。計画が立てやすくなります。