1

今天所有流行的 PHP 框架都使用他们自己的视图层实现，它基于纯 PHP 模板和许多帮助程序。我已经尝试了其中的一些，并且总是发现这种方法给非常简单的事情带来了巨大的复杂性。例如，在 Zend Framework 中，表单和分页使用它们自己的解决方案来定制这些项目的外观。助手重新发明了循环，也提供了相当慢的解决方案，而整个视图层在我看来并不作为一个部分存在，但它的许多功能都委托给了脚本的其他部分。Symfony 和管理生成器中也出现了相同的配置问题，而在 Kohana 中，我被迫在所有表单中复制相同的代码。PHP 真的是视图层的好选择吗？您是否还发现这些实现不方便，或者，

4

2 回答 2

0

还有其他几个模板引擎。但是我一直发现纯 php 是最方便的。我只是更舒服。

我不喜欢 ZF 中的视图助手的一点是，它通常使我的代码更加臃肿而不是更干净。我特别在谈论 $this->url() 助手:)

于 2009-03-28T07:52:52.507 回答
0

现在我喜欢 PHP，但归根结底，它是一种模板语言，不是通用编程语言，也不是面向对象的语言。不要与之抗争。拥抱它。

我查看了一些不同的 MVC 框架，例如 Symfony、CakePHP 和 Zend，但我很难理解这些示例。通常它们是“使用这 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(); ?>

通过明智地使用辅助函数（例如分页链接），上述内容非常容易阅读和调试。我也更喜欢这个模型：

网址：/index.php?inc=blah

索引.php：

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

我觉得这很丑陋，容易出错，甚至很危险。我有一个 PHP 文件的层次结构，它反映了每个页面都是 PHP 脚本的站点结构（从菜单的角度来看）。如果他们有共同的行为，他们都需要它（不是 require_once，它通常用作不良组织的黑客）。

简单、容易、易懂、直接。

似乎很多程序员会在真正需要之前将框架投入其中。我认为这是一种相当懒惰的做法，而且成本很高：今天做出的每一个决定以后都会变得更难改变，所以尽可能推迟做出这样的决定。稍后再引入比现在引入更容易，发现它并没有真正做到你想要的，然后再改变它。

于 2009-03-28T08:06:19.573 回答