宅男程序員給老婆的計算機課程之8：控制器
原創設計模式再“高級”一點，便是所謂的“框架”了。
從事Web開發，一般都會接觸到MVC框架這個概念。
M：也就是Model，直接跟網站數據庫相關。
V：也就是View，是網頁的模版，跟顯示數據相關。
C：則是Controller，相當于網站的業務邏輯。
MVC也不僅僅是應用于網站開發，它的概念實際上植根于桌面軟件，并且在手機軟件開發上也有應用。
MVC本身是一個設計模式，是一個被驗證過的，可以用來很好歸納、管理代碼的軟件開發方式。
基于這樣的設計模式，提供了很多相關的類庫實現，則“設計模式”升級為“框架”。
MVC的任何一個方面，擴展出去講，都可以講上幾天幾夜。
今天只講C。
傳統上，php / asp / asp.net web form等，使用的是所謂的 Page Controller Patterns:http://martinfowler.com/eaaCatalog/pageController.html
Page Controller簡單的說，便是一個網址對應一個程序文件。
所以，我們會看到大量類似： show.php / show.asp / show.aspx 的網址存在，這樣的網址，背后都有相應同名的文件。
這樣的模式，是網站從靜態轉向動態是最自然的改變方便，也最為容易讓初學者接受。
但隨著網站的復雜化，這樣的模式會慢慢顯得不夠方便；比方說，多個不同的網址，映射到相同的處理；比方說，處理的時候，復用共同的資源。
頁面內容的動態化，同一個程序文件，顯示的內容是動態生成的 - 根據不同的query string，生成不同的內容，如：show.php?id=1234
網頁程序內部，實際上是需要解析網址中的query string，并做不同的操作。
這實際上是一個映射的過程，將網址映射到相應的處理。
為了方便做這樣的映射，慢慢的出現了所謂的 Front Controller Patterns:
http://martinfowler.com/eaaCatalog/frontController.html
這是通過某種機制，將符合各種規則的網址請求映射到程序中的一個類，或者是一個函數處理。
一般上，是使用正則表達式解析網址，并映射。
將網址映射到一個類；
- urls = ("/home", "hello")
- app = web.application(urls, globals())
- class hello:
- def GET(self):
- return 'Hello, world!'
將網址請求映射到類，是相對較“重”的處理方式，比方說，需要處理類的初始化等等。
有的框架，也可以是一個函數，則相對“輕量”一些：
- (r'^$', 'home'),
- def home(request):
- return HttpResponse("Hello, world.")
類、函數，均各有優劣，但實際差異很小：
映射到類的方式，往往還會根據不同的HTTP header映射到類里面中相映的函數，比方說，將對 /home 的HTTP GET請求映射給 hello 類的 GET 函數；而對 /home 的 HTTP POST請求映射給 hello 類的POST函數。
這部分 url routing的設計與實現，各種語言、平臺上的功能均向正則表達式靠攏，大同小異。
有的可能專門為 restful 做了優化，但即便木有，自行實現也并不復雜。
很多請求，都會有一些常用的默認處理，比方說，檢查用戶是否登陸，檢查用戶是否有權限等等。
這些業務控制邏輯，是完全可以復用的。
在Page Controller的場景下，一般是通過繼承來實現；而Front Controller場景下，而一般通過函數修飾符的風格實現，如：
- class UploadImgHandler(BaseHandler):
- @tornado.web.authenticated
- def post(self):
- XXX
(上述代碼，實際上既使用了繼承，也使用了修飾符。)
Controller的改進，目的在于更加方便的維護代碼、修改業務邏輯。
如果程序員有良好的開發風格，基本是使用最基礎的php page controller，也可以達到類似的效果。
各種“先進框架”，實際上是將常用的模式抽象出來，并通過便利的約定方式向程序員開放；如果程序員缺乏維護代碼的意識，也很可能將良好的約定習慣用濫。
需要了解的，是為什么各框架的controller設計會有這樣的設計，并用好；而不是死板的遵循“開發指南”。
在簡單業務場景下，實際上page controller會更加方便。
有這么一個“定理”：概念越簡單的模式，在處理簡單場景時，是越便利；但隨著場景復雜化，簡單的模式會越來越難以維護。
而概念相對復雜、高級的模式，處理簡單場景時，會相對麻煩；但隨著場景復雜化，則比簡單的模式容易維護。
“復雜度是守恒”的：
模式簡單，維護則復雜。
模式復雜，維護則簡單。
一個復雜的地方變簡單了，則另一個地方會變復雜；保持代碼結構的清晰，不要自己給自己添麻煩。
什么叫自己給自己添麻煩？
普通復數形式，加s: pigs / cats / dogs
已經可以很好了，但偏生有人要增加不規則復數：
sheep / mice / wives
這種就是自己給自己添麻煩。
作業：
1. 說說對 restful 的理解
2. 什么是 reverse proxy ?
51CTO系列：
