单纯用MVC不够，因其仅划分三层边界而未约束层内职责，易导致展示逻辑分散、重复和混杂；需引入策略模式封装“怎么展示”，实现展示逻辑的统一管理与灵活替换。
业务逻辑与数据展示必须分离，否则视图里混着 mysqli_query、控制器里塞着 HTML 拼接、模型里写 echo，项目一过三个月就没人敢动。
为什么单纯用 MVC 还不够？
MVC 本身只划清了三层边界，但没约束层内职责。常见问题包括：
- 控制器里直接调用
file_get_contents渲染模板，绕过视图层统一处理 - 模型中返回的是已拼好的 HTML 字符串，而非原始数组或对象
- 同一份用户数据，在
UserController::show()和AdminController::listUsers()中各自写一遍格式化逻辑（如日期转中文、状态映射为标签）
这时候光靠 MVC 结构压不住逻辑蔓延——你需要把“怎么展示”这个决策，从控制器和视图中抽出来，交给策略模式管。
用策略模式封装展示逻辑：以用户状态渲染为例
假设用户状态字段是数字 status（0=待审核，1=启用，2=禁用），不同页面要渲染成不同形式：
立即学习“PHP免费学习笔记（深入）”；
- 后台列表页 → 显示带颜色的 badge：
<span class="badge bg-warning">待审核</span> - API 接口 → 返回字符串
"pending" - 邮件模板 → 返回中文描述 + 换行说明
不推荐在每个控制器里重复写 switch($user['status'])。正确做法是定义一个接口和多个实现：
interface UserStatusRenderer
{
public function render(int $status): string|object;
}
然后在 app/Renderers/ 下放具体类：
-
StatusBadgeRenderer：返回 HTML 字符串（仅用于 Web 视图） -
StatusApiRenderer：返回小写英文键名（"active"） -
StatusEmailRenderer：返回带换行的多行文本
控制器只需注入对应策略实例，调用 $renderer->render($user['status']) 即可。视图里不再判断状态值，只负责把结果原样输出或包裹。
控制器里怎么安全地传递数据给视图？
很多团队用 extract($data) 把数组转成变量传进视图，看似省事，实则埋雷：
- 覆盖已有变量（比如视图里原本有
$title，模型也返回title，结果被意外替换） - 无法静态分析变量来源，IDE 跳转失效
- 调试时不知道
$user是哪来的，得翻控制器找loadView('profile', ['user' => $u])
更可控的做法是强制使用对象容器：
class ViewData
{
public function __construct(
public readonly array $context = []
) {}
public function get(string $key, mixed $default = null): mixed
{
return $this->context[$key] ?? $default;
}
}
控制器调用：$this->loadView('user/profile', new ViewData(['user' => $user, 'renderer' => $badgeRenderer]))；视图里统一用 $data->get('user') 或 $data->get('renderer')->render(...)。类型明确、IDE 可推导、不会污染作用域。
模板引擎不是万能解药，关键看你怎么用
用 Twig 或 Smarty 能隔离 PHP 逻辑，但很多人仍把它当“更安全的 echo”来用：
- 在 Twig 模板里写
{% if user.status == 1 %}...{% endif %}—— 状态含义又泄露到视图了 - 用
{{ user.created_at|date('Y-m-d') }}—— 时间格式硬编码，改需求就得扫全站模板
真正解耦的做法是：
- 模型返回原始时间戳或
DateTime对象，不格式化 - 所有格式化逻辑收归策略类（如
DateFormatStrategy），控制器传入实例 - Twig 中只调用预注册的函数：
{{ user.created_at|format_date('short') }}，背后由策略决定具体格式
这种组合下，MVC 提供骨架，策略模式填充血肉——业务规则变，只需换策略；展示方式变，不动模型和控制器；连视图都可能复用同一套逻辑，只是挂不同的渲染器。
