PHP中MVC与策略模式分离业务与展示

在PHP开发中，单纯依赖MVC架构难以真正实现业务与展示的分离，因其仅划定三层边界却不限制层内职责，极易导致展示逻辑散落、重复和混杂；本文提出将策略模式深度融入MVC，专门封装“如何展示”这一核心决策——例如用户状态在不同场景（后台Badge、API响应、邮件内容）下由对应渲染器统一处理，配合类型安全的ViewData容器替代危险的extract()，并推动模板引擎从“写逻辑的场所”回归为“纯展示管道”，最终让业务规则变更只需替换策略、展示形式调整无需触碰模型与控制器，大幅提升代码可维护性、可测试性与长期演进能力。

业务逻辑与数据展示必须分离，否则视图里混着 mysqli_query、控制器里塞着 HTML 拼接、模型里写 echo，项目一过三个月就没人敢动。

为什么单纯用 MVC 还不够？

MVC 本身只划清了三层边界，但没约束层内职责。常见问题包括：

• 控制器里直接调用 file_get_contents 渲染模板，绕过视图层统一处理
• 模型中返回的是已拼好的 HTML 字符串，而非原始数组或对象
• 同一份用户数据，在 UserController::show() 和 AdminController::listUsers() 中各自写一遍格式化逻辑（如日期转中文、状态映射为标签）

这时候光靠 MVC 结构压不住逻辑蔓延——你需要把“怎么展示”这个决策，从控制器和视图中抽出来，交给策略模式管。

用策略模式封装展示逻辑：以用户状态渲染为例

假设用户状态字段是数字 status（0=待审核，1=启用，2=禁用），不同页面要渲染成不同形式：

• 后台列表页 → 显示带颜色的 badge：待审核
• 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 提供骨架，策略模式填充血肉——业务规则变，只需换策略；展示方式变，不动模型和控制器；连视图都可能复用同一套逻辑，只是挂不同的渲染器。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《PHP中MVC与策略模式分离业务与展示》文章吧，也可关注golang学习网公众号了解相关技术文章。