背景
在当前的多屏时代，业务多场景往往需要适应手机、网站、pad、电视或合作方第三方接口等等，不同的“屏”往往对业务数据有不同的需求，有不同的接口调用和约束规范：
那么应该如何组织代码呢？
在后端领域，大家通常使用mvc模式来分离不同的关注点，可惜的是很多同学使用有偏差:
见过不少项目的代码：
- controller里面有很多刺裸裸的sql语句
- controller里面完很多的逻辑判断
- mode里面全是隐式的代码约束
....
控制器的代码组织
通常，我们在处理“输入输出”的时候，使用一个个具体的controller或action来进行处理，我们针对不同的平台，可以有两种方式：
- 不同的controller来处理不同平台的需求
比如
- 一个controller根据输入的条件判断不同的输出
比如：
3，那上面的两种方式那一种更加合适呢？
软件的成本按照大的模块分：
- 开发成本
-
维护成本
在软件什么周期里面，需要不停的修正bug，添加新的业务功能和平台适配，重构以前的业务代码。
一个前提：当前项目经常是多人团队配合完成，这里面需要考虑进行数据修改与维护的可能不是“我”，不是第一个作者，而是其他人在维护或共同维护，在团队开发和软件整个生命周期里面，自己写的代码他人维护是个大概率事件，也许是因为项目资源调动，也许是因为入职离职。
为了尽最大的努力降低日后的维护成本和重构成本，需要尽力将“关注点”进行分离，所以控制器代码组织尽量使用上面的第一种方法。
控制器的代码应该完成那些功能呢？
个人建议：
- 只需完成输入过滤，输出匹配。
- 业务逻辑相关的代码不要直接放到控制器里面
如果把逻辑代码放到controller，里面，会出现下面情况：
web\usercontroller.php （web平台）
function f() {
biz_fetch_1();
biz_fetch_2();
biz_fetch_3();....
}```
api\usercontroller.php（对外api接口）
function f() {
biz_fetch_1();
biz_fetch_2();
biz_fetch_3();
}```
这样会导致不停的重复代码。其实只要写代码随时想到一点：在此处完成的业务逻辑，可能在app环境下可能要使用，在对外合作的api环境下可能要使用，要保持业务逻辑代码只存在于一个地方，就自然可以把相关的业务放到另外的类里面。
业务代码是不是都放到Model里面呢？
设想一个场景，用户支付，至少涉及到UserModel，支付PayModel等多个Model，在跨多个Model进行协作才能完成的业务逻辑，都放在一个Model里面不太合适，因为业务的逻辑归属不是仅仅一个model！
不合理的情形一，都放在controller的方法里面：
function biz() {
$UserModel=newUserModel();
$UserModel->doSth();
$PayModel=newPayModel();
$PayModel->doSth();
.....
}```
如果产品只面向一个平台，只一个地方进行调用，那没什么问题。但是现在产品经常要多目标“平台”，上面的biz就非常可能会在pc，app，api等对外接口里面不断重复，不符合DRY（Don't Repeat yourself)原则。**yourself，不仅仅是指单个等程序员，是指整个开发小组、团队
#推荐将业务代码放到单独的service层里面
service，可以是一些工具类，也可以是以特地命名空间下的类，只需要不在controller里面，也不在与单独的表对应的model里面即可：
比如转账，有个TranServcie，订单，有个UserService
比如这样组织文件
bao\UserService.php
或bao\service\UserService.php
调用的时候用
$UserService->register($data);
$UserService->login($data);
等来完成业务
这样不同的业务场景下，可以复用很多的业务逻辑。针对业务的修改也能集中在特定的地方
#为什么倾向于命名为XxxService而不是的XxxModel呢？
核心其实是为了让真个团队成员在思想认识上有这么一个业务逻辑层的概念，避免Model和数据库表直接对应的Model的混淆。
同时理解了这个业务的逻辑启示是一个服务，在做内部服务化的时候，把Service发布为一个个服务是一个思想上自然延伸的概念。
#历史项目怎么办？
找时间慢慢重构呗。
#总结
**1，编写代码的时候考虑业务代码可能会在其它平台复用**
**2，控制器的方法只做输入的过滤和输出的格式匹配**
**3，涉及到多个Model的业务，放到xxxService里面**