使用分层 PHP/HTML 设计？这是正确的吗？答案

【问题标题】：Using tiered PHP/HTML design? Is this right?使用分层 PHP/HTML 设计？这是正确的吗？
【发布时间】：2012-01-27 13:53:00
【问题描述】：

我在某处读到，您应该将网页分为 3 层：Fetch、Logic、Presentation。

获取：从数据库/会话等中获取信息
逻辑：计算你需要什么
演示文稿：显示 HTML

首先，这是个好主意吗？我可以看到一些明显的好处（组织，易于修改）。其次，看到这个模型回显 HTML 不好，我应该将我想要的 HTML 存储在变量中吗？

例子：

<?php

/** fetch **/
include("session_validator.php");

$secret = $_GET['secret'];

mysql_connect($host, $user, $pass);
// connect and query
$username = mysql_result($result, 0, 'username');

/** logic **/
if (isset($secret)) {
    $message = "You know the secret!";
} else {
    $message = "The secret is wrong";
}

/** presentation **/
?>
<html>
<body>
    Username: <?php echo $username; ?> <br>
    Secret? <?php echo $message; ?>
</body>
</html>

重申我的问题，将我的信息存储在$message 并在演示之前关闭PHP 部分是一个好主意吗？还是我误解了整个分层概念？

【问题讨论】：

标签： php html coding-style standards

【解决方案1】：

这种设计通常被称为MVC（模型视图控制器），和你描述的有点不同：

控制器 - 接收请求并处理它们的部分。它同时调用 Models 和 Views。
模型 - 逻辑部分，这是繁重的 PHP 编码将生效的地方。这是您从数据库/文件中获取信息、进行计算然后将数据返回给控制器的部分。
视图 - 应用程序的展示部分，通常它主要包含 HTML（和/或其他客户端语言），它是呈现给客户端的页面。 Controller 将 Model 中的数据传递给它，然后可以对其进行解析（Views 通常允许其中包含 PHP 代码）并呈现.

我认为这是一个很好的模式，因为它允许清晰的分离和易于维护。它还允许您将前端和后端之间的工作分开（特别是如果您的每一侧都有不同的开发人员！）。

至于回显部分，您将回显 HTML 的唯一位置是在您的 View 中，所以那里没有问题。

我建议你看看一个有据可查的框架（例如codeigniter）并开始阅读。

【讨论】：

所以回显 HTML 不被认为是不好的做法？我在编码时尝试坚持使用 PEAR，这是否意味着我应该结束 PHP 块并在需要时使用小型 PHP sn-ps 启动纯 HTML 或简单地回显 HTML？
分离原则说要保持逻辑和表示在不同的页面上，MVC 擅长于此，请仔细阅读我的答案。回显大量 HTML 是实际上被认为是不好的做法，不要犯错。

【解决方案2】：

我个人使用一个面向对象的 php 框架来处理所有正在进行的任务，这使得接收请求的页面只有 5 行（左右）长。这种方式更好，因为您可以稍后专注于您的视图，并将所有代码放在同一个地方，这样您就不必到处寻找它。

但请相信我，每个程序员都有不同的方法，所以没有真正错误的做事方式。

【讨论】：

这听起来很有效。您使用的是哪个框架？我在看codeigniter。
我通常创建自己的框架。例如，如果我有一个社交网站，我会有 get_username_by_id($id) 之类的函数，这将真正加快代码编写的过程。

【解决方案3】：

这是一种有效的方法。但是，当您在 HTML 中输出变量时，您应该确保正确地对其进行转义。直接从 PHP 执行它意味着使用 htmlentities()。我建议你围绕它编写一个包装函数，因为它需要的参数有点乏味。

您还可以使用 Twig 或 Smarty 之类的模板引擎，这通常会使转义更容易一些，并提供用于处理布局的构造。

但是，您的方法没有任何问题。只要在实际代码和显示逻辑之间有明确的分离，以后就不会太麻烦了。您可以将 HTML 部分移动到一个单独的文件中，并将其从另一个页面中包含进来，以使分离更加清晰。

我自己使用框架，但如果你还在学习，保持简单并不是一件坏事。

【讨论】：