现在的PHP框架基本上遵循的都是MVC模式，几乎很多的逻辑判断和业务代码就几种在C层，这也导致一个问题，一个方法代码少则几十行，多着几百行，代码的优化就显得特别的重要。我们以几个常见案例来说明。

一、新增和修改业务合并在一起

很多的时候的操作大都是新增和修改操作，而新增和修改的页面又是一模一样的，就是修改和新增有一些业务不一样，针对这种情况有一些优化，这里我们以新增用户，这样每个项目都有的模块来举例。我们贴一部分代码

这里的账户新增和添加我们共用一个方法，而不是建立的两个方法，以往我们是建立了两个方法，现在不是的，而且以往我们再渲染页面的时候又是一个方法。所以这里的actionSet()方法有三个功能

代码片段1

渲染页面，如果有数据我们会加载数据，如果没有，我们也不查询这个数据。对于像id这样的数据，可以强制转换为整型，但是我又觉得不妥，应该是校验数据是不是正整数，比如字符串‘123abc'强制转换为整数就是123，所以这里提供的不是一个好的方案，应该是用正则表达式匹配是否是正整数，如果不是就不查询数据，尽量减少不必要的数据库查询，资源很宝贵的。记得变量info这里要初始化，不然会报info未定义。强制转换也不是不可以，但是尽量少使用

参数校验部分就不贴出来了，对于客户端填写的所有数据都应该校验，这是必须做的事情。

代码片段2

有的数据在新增的时候是有唯一性监测的，不就可以胡乱新增，比如账户就是这种。修改的时候呢，也需要这种判断，但是是自己本身的话是不需要判断的，所以这里我们在判断该用户名是否已经存在的时候加了一个$info['uid']!=$id，这可能显得有点多余，但是在修改数据的时候就有用了，试想修改的时候查询到的用户信息的uid是不是和自己的uid一致？是的，那需要检查唯一性嘛？不需要，所以这里我们多加了一个id是不是自己的id检测，如果是就修改。

以前我的做法是两部分，一部分是有客户端提交的参数有id的情况，表示是修改，就通过id获取数据，如果数据存在并且权限合适就修改。另一部分新增，通过login_name寻找是否有存在的用户，这种做法代码至少增加一倍，逻辑稍微有点多，但是不是合适的做法，这种做法就显得很好。

所以下一次需要检查唯一性的数据做修改和新增操作的时候，用此方法来判断，就很简单了。思考一下这个问题，我们可以把$info['uid']!=$id这个判断移到where()方法里嘛，用数据库来查询获取结果，是可以这样做的，但是这增加了数据库的压力，在可以获取数据数据的前提下，其他的判断操作交给程序来执行，这样可以减少数据库的查询压力，还可以减少建立不必要的索引。

代码片段3

真正的数据库操作，还有一些数据判断，比如新增的时候需要初始化的数据，在修改的时候就不需要了，比如我们这里的盐值、新增时间、头像...，模型对象是怎么来的也有技巧的，比如修改的话就来自于我们上面查询，这说明是数据修改，如果没有就是新增，需要我们new User()来获得模型对象， 然后新增和修改都会修改的数据我们放在外面，不要再if/else里都加这些部分。

模板代码片段

因为新增和修改都是共用一个模板，所以变量info里可能是没有元素的，所以我们会使用<?=$info?$info['login_name']:'';?>来做判断，这里我们使用的是三元运算符，没有值我们给一个空值

像这里的密码就有点奇怪了，密码并不是数据库存储的密码，因为数据库存储的密码是加密后的，所以放在这里也没有用。还有用户不是每次都修改密码，针对这种不是必须修改，但是不知道用户到底修改没有修改，这种特殊的操作，就要用到一些方法来操作了。这里我们在常量服务类中建立一个default_password（默认密码）。 所以我们模板有一个判断操作<?=$info?ConstantMapService::$default_password:'';?>，修改的时候才有默认密码，新增的时候就没有了。这对我们后台在判断是不是默认密码的时候有帮助。

常量类

很多的不变的操作，我们把它放在了ConstantMapService里面，也可以放在config.php配置文件里面，但是我个人觉得放在这种类里面来获取更通俗易懂一点。这个问题有点复杂，到底那些应该写在里面，那些不可以，我们后面在讲，这里先贴出来看一下，回顾一下。

密码修改判断1

密码到底是修改了还是没有修改，通过用户传递过来的数据和我们默认密码做对比，如果不相等就修改了，就修改密码。像新增的时候，login_password这个input是空的，用户必须填写才可以提交表单的，所以用户填写的密码会和我们的默认密码一样，导致密码没有填写，所以这里的判断应该移动到修改里面，而新增必须设置login_pwd属性。就变成了这样

密码修改判断 2（改良）

修改过后的判断是可以满足要求，但是可读性变的非常的差，取反还或操作，一眼是不知道这个判断是有什么意义的。那还有第二种可行的方案，把操作移动到if($info)...else里面，如下

密码修改判断3（改良）

这种方法确实把判断改变的简单，但是设置login_pwd就写了两次，如果要改变密码操作的话，都得修改，而且if/else内部逻辑也变得复杂起来。我觉得应该是把“密码修改判断2”写一些注释说明，方便别人理解。如下：

密码修改判断4（改良）

可以看到，新增和修改业务合并也不是很简单，不仔细观察室得不出好的解决办法的，我觉得在修改的时候要有一种想法，那就是，不要简单的业务合并，一定有可以简化的方法存在，在试试

想法：1.其实这种业务合并也带来了很多好处，首先页面只有一个了，前端的工作量少很多，接口也只维护一个，所以就工作量和延展性上来说都有很大的好处。第二，如果提交的id数据库不合法，数据查询不到，也不会弹出一错误页面，而是一个新增页面，这样就友好很多了，系统也简单很多，不用来回的跳转。第三还可以磨炼简化代码的能力，分开后自己想写多少就多少，合并在一起就不一样了，尽可能靠在一起，把差距拉小。

2.我们可以看到我们在操作数据库的时候是面向对象的方式，像TP5.0、Yii2都可以这样操作了，但是像TP3.2还不完全可以，至少在方法上就不可以实现，所以尽量使用面向对象的方式操作数据库。如果不太懂，看框架模型相关的手册，那种方式简单容易理解，就先使用那种。

二、找不到数据就不给你看

有的页面和新增修改不太一样，如果没有数据，这个页面是空的，完全没法显示，针对这种情况，以前我就把这个页面给到，最多给个判断，参数不合法，但是后来想想太多，地址栏跳转你返回一个数据不合法，用户不会懵逼嘛，会的啊。所以好的方法应该是有的，比如

1.应该是友情提醒，比如你找到的数据不存在，将返回到某个页面，

2.比如根据匹配你可能找的是这个数据，显示可能显示的数据，比如你找“小明”但是你输入了“小名”，系统智能提示你可能找的是小明，这是很多网站采取的方法

3.数据找不到我就不给你，就给返回到上一个页面去，就这么简单，也是最简单的一种方案，这里我们提供这种方案。    

用户详细信息

这里我们可以看到，找不到用户的数据我们就返回到指定的页面。 这种方式最为简单，前端可以不做任何的判断，但是呢，不太友好。根据自己的业务来选择合适的方法。

---------------------------明天更新删除数据和恢复数据的合并优化方案