三. 能不能使用MVC架构进行Webform的开发

    有人尝试使用ASP.NET MVC 框架来进行webform方式的开发，我个人是不欣赏这种做法的，这就好比在使用LINQ的项目中又同时使用SQL语句一样“怪异”，这在代码的整体风格上会让人产生迷惑，不是吗？当然老赵也在他的视频课程中提到在webform页面中使用一些MVC功能（比如：ModelBinder等），但我想老赵的本意决不是让这种混合方式的开发大行其道，必定这是“非主流”，所以孰轻孰重还是要大家自己把握的。

    四. 传统的三（N）层架构与MVC，以及MVC与MVP关系

    本文所说的三层架构指：表现层（显示层）， 业务逻辑层， 数据访问层（持久化）。如果大家非要“生搬硬套”的把它与MVC扯上关系的话，那我就只能在这里"强扭这个瓜"了，即：

    三层架构中"表现层"的aspx页面对应MVC中的View（继承的类不一样）

    三层架构中"表现层"的aspx.cs页面(类)对应MVC中的Controller,理解这一点并不难，大家想一想我们以前写过的Redirect，当然它本身就是跳转了一些链接页面，而MVC中的Controller要做的更爽，它控制并显示输出了一个视图。即然所起到的作用都是对业务流程和显示信息的控制，只不过是实现手段不同而已。

    三层架构中业务逻辑层和数据访问层对应MVC中的Model(必定View和Controller已找到“婆家”，剩下的Model只能是业务业务层和数据访问层的了，呵呵)。但其实微软的一些MVC示例项目中对这个问题理解的并不是这样简单，这一点在我之前的关于两个MVC示例的思考(MVCStore和Oxite) 已阐述过，就不多说了。

    其实明白了这个关系，就可以尝试把以前的三层结构迁移到MVC框架下，当然在这个过程中肯定会遇到这样或那样的问题，但原则就是把将MVC的优势发挥到极致，要不然还不如不做。说到这里，其实早在N年前就有人提出使用FrontController（前端控制器）来实现对HTTP页面请求的路由跳转（包括数据的展现），说白了就是使用HttpHandler来进行页面请求的处理和数据绑定，而不是完全“指望”普通的页面访问重定向等。这样做的目的，就我而言与Routing中的Controller和Action的出发点标是一致的，只不过Routing实现的更优雅同时也更底层一些。

    说完了三层架构，再看看MVC与MVP，其实在这之前我们有必要看一下这张图:

    看完了上面的图，大家就会发现MVP与MVC最大的一个区别就是“Model与View层之间倒底该不该通信（甚至双向通信，如图）。我想这也是目前做这两方面研究的专家所互相争论的战场。必定各有各的好处和因好处要付出的代价。起码在MVP模式下的Presenter要拥有“绝对权力”。如果没有它，MODEL与View就是两个孤岛，尽管各有各的地盘（完全解耦），但不会给企业带来什么有用的价值。所以我这里有一个比喻来形容MVP中的：

    Presenter ----就是一个控制欲极强的女人，甚至就连“用什么姿势”，它都要管一管。