ThinkPHP 3.2 与 面向对象编程

ThinkPHP 3.2 与 面向对象编程

首先，这只是我突然想到的东西，所以肯定不是很专业的，但是对我来说却像是明悟一样。

例如一个带我的大哥的习惯是这样的，针对数据库中一张表的增删改查分别对应于一个控制器下的4个操作：add delete edit lst，如果该页面中有提交表单的，就使用form action="?"的方式返回同样控制器下的相同方法，接着使用IS_POST进行截取，这样获取表单输入页面，以及处理表单的代码都会在同一个控制器下的相同方法内部(如果有针对多表操作的，就写在对应模型的自动完成中)。这样从外部看进去就会显得代码很整洁，各个操作的代码均在一个控制器的一个方法内部，互相之间泾渭分明。

可是这样我感觉不对，首先，这样肯定不是面向对象的，就控制器与方法的角度来说，类比到类与操作，一个操作负担了太多内容，既要获取输入页面，也要处理表单提交数据，就好像一个操作内部的功能应该是简洁的，每个方法都只承担一部分责任。就像Laravel一样，一个方法专门用来获取输入页面，一个方法专门用来处理数据。

而从这样的角度考虑，可能这样的形式更加好，首先后端人员根据设计稿确定数据结构与数据库，接着将字段名称给前端人员，前端人员主要负责友好的交互体验，在需要向后台获取数据时，后台提供各种接口即可，这样，后台无需关心前端特别在意的业务流程，专注于数据处理，而前端也无需关心后端会如何处理数据，只需调用相应的接口即可，这样好像能做到前后端分离，高效开发。

同时感觉存在一个很致命的误区，例如PHP开发人员都具有基础的全栈能力，即可以编写前端页面(当然，美观是另说的)，这样他们就会这样思考：“首先获取输入页面，这个页面需要什么数据，之后表单提交到哪里，提交成功之后跳转的链接地址是哪里，之后怎样怎样之类的”。这样后台的一个理念就是业务逻辑是怎样的？？？这样个人感觉是错误的，当后台开始思考业务逻辑时，不可避免的就会出现数据错误时，整体结构逻辑错误，甚至当一个环节扣着一个环节的时候还需要从头开始思考是哪个环节出现了错误，这样的查找，感觉很浪费时间的。如果这样思考呢？我只负责处理各个环节中前端提交过来的正确的数据，各个数据假设都正确(当然，这不妨碍你进行数据的有效性验证)，该控制器下的该方法仅处理正确的数据，如果数据处理复杂，则分开在多个方法中执行，保证每个方法都仅处理一个数据，这里不是为了提高方法的重用性而进行拆分，而是为了使各个方法都只负担数据处理中的一部分。使用上述方法的一个重点就是数据！！！数据库的重点就是维护业务逻辑的关键，只有数据库数据正确，各个方法才能有效执行，这样，就把各个部分的功能做了区分：

• 前端：交互以及展示数据，提交数据
• 后端：处理前端提交数据，提供前端需要展示数据
• 数据库：保存数据，展现业务逻辑中的各个环节