PHP Model 最佳实践：提升代码质量与可维护性指南

发布日期： 2025-09-24 阅读量： 作者： admin

今天捣鼓了一下PHP的Model这块儿。以前写代码比较随意，逻辑、数据库操作啥的，有时候就直接堆在控制器或者干脆一个文件里，代码一长，自己看着都头疼，别说后面维护了。

为啥要弄这个Model？

主要还是代码写多了，越来越感觉乱。特别是数据库操作那块，到处都是SQL语句，改个字段或者表名，得翻半天文件，累死。看很多框架都搞了MVC，M就是Model嘛专门处理数据这摊子事，想着自己也得学学，规范一下。

开始动手实践

一开始没想太多，就想着建个类文件，比如叫`*`，专门用来处理用户相关的数据库操作。最简单的想法，就是把以前写在别处的SQL语句搬进去，封装成一个个方法。

第一步：创建基础类

我就先创建了一个`UserModel`类。里面先放了个空架子，想着怎么把数据库连接弄进来。最初图省事，直接在类的方法里写数据库连接代码，比如 `mysqli_connect` 或者PDO实例化的代码。搞了两次发现不对劲，每个方法都连一次数据库？或者在构造函数里连？那每个模型都自己管连接？感觉还是乱。

第二步：处理数据库连接

后来琢磨了一下，数据库连接应该是独立的，或者说，统一管理的。我搞了个简单的数据库连接类或者就一个全局的PDO实例（虽然全局不太但实践初期先这样跑起来），然后通过构造函数传给`UserModel`。这样`UserModel`就不用关心怎么连接数据库了，只管用就行。

php

// 大概是这么个意思，不是完整代码哈

// class UserModel {

// private $db;

// public function __construct($db_connection) {

// $this->db = $db_connection;

// }

// // ... 其他方法

// }

第三步：封装常用操作（CRUD）

接下来就是体力活了。把常见的增删改查操作一个个封装成方法：

`getUserById($id)`：根据ID查用户，里面就是 `SELECT FROM users WHERE id = ?` 这类的SQL。
`createUser($data)`：插入新用户，接收一个包含用户信息的数组，然后执行 `INSERT INTO users (...) VALUES (...)`。
`updateUser($id, $data)`：更新用户信息，执行 `UPDATE users SET ... WHERE id = ?`。
`deleteUser($id)`：删除用户，执行 `DELETE FROM users WHERE id = ?`。

这里特别注意了一下，SQL语句尽量用预处理（Prepared Statements），防止SQL注入，这个是基本操作了。

实践中的感觉和问题

好处是显而易见的：

控制器干净多了。以前控制器里一堆SQL，现在就变成 `$userModel->getUserById(1)` 这样一行调用，清爽！
代码复用性强了。需要获取用户信息的地方，直接调用模型方法就行，不用重复写SQL。
维护方便了。以后用户表结构变了，或者SQL需要优化，直接改`UserModel`就行，其他地方不用动。

也遇到点头疼的事：

关联关系处理： 如果一个用户有多篇文章，那查用户的时候要不要把他写的文章也查出来？这就涉及到模型之间的关联了（比如`UserModel`和`ArticleModel`）。这块儿处理起来就比较复杂了，得好好设计，不然模型又会变得臃肿。这回实践暂时没深入搞这个。
数据校验： 用户输入的数据（比如创建用户时的`$data`）应该在哪里校验？是控制器里校验，还是模型里校验？我倾向于模型里也做一层校验，保证存入数据库的数据基本是干净的。
返回数据格式： 方法返回的是数组还是对象这个看个人习惯和团队约定。我一开始用的数组，后来觉得返回对象（比如`stdClass`或者专门的`User`实体类）可能更面向对象一点。

最终效果和小结

搞了一天下来，虽然只是做了些基础的封装，但效果还是挺明显的。把数据处理逻辑从业务逻辑里抽出来，放到Model层，整个代码结构清晰了不少。

虽然还有很多细节可以优化，比如数据库连接的管理方式、模型关联、更完善的数据校验等等，但这个方向是对的。以后再写项目，肯定会坚持用这种方式来组织代码，至少查问题、改东西的时候，能省不少力气。实践出真知，还得继续捣鼓。

上一篇: 存储优化技术怎么降低成本？这几个方法简单又有效！

PHP Model 最佳实践：提升代码质量与可维护性指南

随便看看