互聯網創業的準備--框架：從MVC到開放API

作者：sink_cup 2012-09-27 13:49:54

MVC是傳統web服務的常用框架，直到出現新的需求：私有API、開放API，還有業務龐大后進行soa拆分，這就需要新的框架了。

關于MVC，有一個經典講解：http://www.symfony-project.org/jobeet/1_2/Doctrine/zh_CN/04

對這張圖進行修改和細化：

1、controller只支持http(s)，不支持cli命令行

http參數的獲取和cli完全不一樣，web服務用不上cli，所以只支持http(s)。

2、一個uri應只支持一種http method

從安全和http規范兩個方面來說，一個uri應只支持一種http method，不能讓一個請求即支持get又支持put、post，所以在controller中的每個action都要指定一種http method，如果請求不符合method，返回錯誤。

安全：假如修改個人簽名的頁面提交地址為http://example.com/user/status，參數為content=xxxx，用戶請求時驗證本人cookie即可。這個頁面接口應該只支持post，如果同時支持get，會出現什么問題？user 1發表了一張圖片<img src="http://example.com/user/status?content=某商城促銷，地址xxxxx" alt="" />，很明顯這張圖片是無法顯示的。當user 1的所有好友user 2、user 3看到這張圖片時，瀏覽器嘗試載入圖片，就會自動把user 2、user 3的簽名改成廣告。這就是典型的sns攻擊的原理。

http規范：http://book.douban.com/subject/3094230/

3、MVC各層職責與禁止

index.php：職責——作為入口——根據路由規則，把uri請求映射到某個controller；作為出口——接收controller層返回的數據，然后輸出

controller：職責——取http數據$_GET、$_POST、put、delete，然后作為參數傳遞給model層，把model層返回的數據傳遞給view層。一個uri只支持一種http method。禁止——使用$_REQUEST。

model：職責——處理業務，向下調用dao（數據訪問對象），由于不知道下層用的是什么sql，所以無法寫sql。禁止——寫SQL，取http數據（$_GET、$_POST）。

dao：職責——根據原子業務，封裝各種存儲（mysql、pgsql、mongodb、hbase、memcache、redis、file）。確保當從mysql遷移到pgsql時，對外接口輸入和輸出不變。禁止——對外暴露用的是什么sql。

view：職責——只對數據進行顯示格式處理。禁止——業務邏輯。

4、輸出

頁面返回html，訂閱是atom。

5、異常

經過了PP面向過程的初級階段，進入中等階段class + return false的OOP，再進入高級階段class + exception的徹底OOP，就會發現OOP的簡潔易于維護。

Exception從底層說起比較清晰。

dao：catch 數據庫異常（php是PDOException），throw 自定義錯誤碼DaoException（打詳細log，這種數據庫錯誤應由log平臺發出警報給工程師）。

model：catch DaoException，throw 自定義錯誤碼ModelException。

controller：catch ModelException、catch所有Exception，return http狀態碼、content-type、數據、模板名稱。如果是http狀態碼是302，還需要return uri。

index.php：index.php作為出口，接收到controller傳來的結果，header輸出http狀態碼，根據http status code決定是跳轉還是輸出，根據content-type決定是輸出html、json還是atom。

todo參考：《錯誤碼與狀態碼》

細化之后如下圖：

todo細化：view層之多模板templates、view層之多layout與模塊化、bigpipe

MVC框架細化到這個程度，能很好的支持傳統web服務，直到出現了新的挑戰：

1、移動互聯網的需求，官方app需要api（開放或私有）：iPhone、Android智能手機逐漸普及，在手機上使用互聯網服務更方便，各公司推出官方手機app，需要api。

2、開放帳號和數據的需求，第三方app需要api（開放）：隨著sns的興起，各大sns社區發現開放數據給開發者app，能夠形成生態圈，能夠盈利，OAuth這種授權方案流行了起來。開放的數據如果屬于用戶，那需要先開放帳號，用戶登錄授權第三方app獲得頭像、好友列表。如果是地圖這種自有數據，則無需開放帳號。

3、開放帳號的需求：為什么到各個網站都要重新注冊呢？于是出現了OpenID，但是使用不夠方便，小白不容易理解，而且OpenID只做認證，各公司如果支持OpenID沒有什么額外的價值。后來各社區開放數據時，采用了OAuth，OAuth用于授權也包含了類似OpenID的認證功能。所以現在流行用OAuth登錄，而不是OpenID。比如在別的網站上或者app里“用Google帳號登錄”、“用微博帳號登錄”、“用QQ帳號登錄”并且授權導入頭像。

4、業務龐大后，按照soa進行拆分，也會面臨跨產品線（服務）如何內部調用的問題。參考淘寶的數據拆分演進。

框架進化如下：