宅男程序員給老婆的計算機課程之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系列：

1. 宅男程序員給老婆的計算機課程之0：認清本質
2. 宅男程序員給老婆的計算機課程之1：認清實際
3. 宅男程序員給老婆的計算機課程之2:怎麼看待牛人
4. 宅男程序員給老婆的計算機課程之3:架構比較
5. 宅男程序員給老婆的計算機課程之4:SQL vs NoSQL
6. 宅男程序員給老婆的計算機課程之5:設計模式
7. 宅男程序員給老婆的計算機課程之6:模版引擎
8. 宅男程序員給老婆的計算機課程之7：運維的重要性
9. 宅男程序員給老婆的計算機課程之8：控制器
10. 宅男程序員給老婆的計算機課程之9：數據模型
11. 宅男程序員給老婆的計算機課程之10：作，就對了！
12. 宅男程序員給老婆的計算機課程之11:域模型