背景
在當前的多屏時代，業務多場景往往需要適應手機、網站、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里面**