设计模式再“高级”一点，便是所谓的“框架”了。
从事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系列：
- 宅男程序员给老婆的计算机课程之0：认清本质
- 宅男程序员给老婆的计算机课程之1：认清实际
- 宅男程序员给老婆的计算机课程之2:怎么看待牛人
- 宅男程序员给老婆的计算机课程之3:架构比较
- 宅男程序员给老婆的计算机课程之4:SQL vs NoSQL
- 宅男程序员给老婆的计算机课程之5:设计模式
- 宅男程序员给老婆的计算机课程之6:模版引擎
- 宅男程序员给老婆的计算机课程之7：运维的重要性
- 宅男程序员给老婆的计算机课程之8：控制器
- 宅男程序员给老婆的计算机课程之9：数据模型
- 宅男程序员给老婆的计算机课程之10：做，就对了！
- 宅男程序员给老婆的计算机课程之11:域模型
本文转自 Wuvist 51CTO博客，原文链接:http://blog.51cto.com/wuvist/847713
