1

現在、一般的な PHP フレームワークはすべて、純粋な PHP テンプレートと多くのヘルパーに基づく独自のビュー レイヤー実装を使用しています。私はそれらのいくつかを試してみましたが、このアプローチは非常に単純なことに大きな複雑さをもたらすことに常に気付きました。たとえば、Zend Framework のフォームとページネーションでは、独自のソリューションを使用してこれらのアイテムの外観をカスタマイズします。ヘルパーはループを再発明し、非常に遅いソリューションも提供します。ビューレイヤー全体は、私の意見では一部として存在しませんが、その機能の多くはスクリプトの他の部分に委任されています。Symfony と管理ジェネレーターで同じ構成の問題が発生し、Kohana では、すべてのフォームで同じコードを複製することを余儀なくされました。PHP は本当にビュー レイヤーに適しているのでしょうか? これらの実装も不便だと思いますか、それとも多分、

4

2 に答える 2

0

他にもいくつかのテンプレート エンジンがあります。しかし、純粋なphpが最も便利であることが常にわかっています。私はそれでより快適です。

ZF のビュー ヘルパーについて私が気に入らなかった点は、通常、コードがクリーンというより肥大化することです。私は特に $this->url() ヘルパーについて話している:)

于 2009-03-28T07:52:52.507 に答える
0

今では PHP が好きですが、何よりもまず、PHP はテンプレート言語であり、汎用プログラミング言語でもオブジェクト指向言語でもありません。それと戦わないでください。抱きしめて。

Symfony、CakePHP、Zend などのいくつかの異なる MVC フレームワークを見てきましたが、例を理解するのに苦労しています。通常、「これらの 17 個のファイルを使用して、'Hello world' プログラムを作成できます!」というものです。は？！？！

問題が発生する前に問題を解決するための複雑さなどがありますが、これらの重量のある (重量のある) フレームワークが本当に価値をもたらすとはまだ確信していません。

私は「フレームワークなし」フレームワークのファンです。これは本当に「独自のロール」ですが、それが最も無駄のない、最もクリーンな最終結果につながると思います。

Smarty についても同じように感じます。SO の多くの人は Smarty の大ファンですが、なぜ自分のテンプレート言語にテンプレート言語を追加するのか、私には理解できませんでした。

最終的には、ほとんどの場合、この種の PHP スクリプトを作成することになります

<?
require 'config.h'; // set up constants, DB connections and so on
page_header('My Page'); // page header, site menu and so on
deny_unregistered(); // security
if (/* user submitted page */) {
  $valid = validate_form(/* validation rules */);
  if ($valid === true) {
    // do db changes
    // redirect user ie POST+REDIRECT+GET
  } else {
    // output error messages
  }
}
?>
// display page
<? page_footer(); ?>

ヘルパー関数 (ページネーション リンクなど) を適切に使用すると、上記は非常に読みやすく、デバッグしやすくなります。また、このモデルよりもはるかに好きです。

URL: /index.php?inc=blah

index.php:

<?
require "$inc.php"; // hopefully you sanitize this but so many don't
?>

これは見苦しく、エラーが発生しやすく、危険でさえあると思います。各ページが PHP スクリプトである (メニューの観点から) サイト構造を反映する PHP ファイルの階層があります。それらが共通の動作をしている場合、両方がそれを必要とします（通常、貧弱な組織のハックとして使用されるrequire_once ではありません）。

シンプル、簡単、わかりやすい、わかりやすい。

多くのプログラマーは、実際に必要になる前に、フレームワークをミックスに投入するようです。これはかなり怠惰な慣行であり、大きな代償を伴うものだと思います。今日下されたすべての決定は、後で変更するのが難しくなるため、このような決定を行うのはできるだけ先延ばしにしてください。何かを後で導入することは、今何かを導入するよりも簡単です。

于 2009-03-28T08:06:19.573 に答える