ASP.NET MVC框架的面面观
2010-06-22 16:15 bennieguo 阅读(198) 评论(0) 编辑 收藏 举报
前言
写这篇文章的目的，是想总结一些东西，以帮助朋友们更好的使用这个框架。但是，我又不像把官方列举的哪些优势、功能翻译过来列举在这里。所以，我想干脆我就纯从个人观点上对这个框架评论一下吧。说的不好的，不对的还请批评指正。
ASP.NET MVC——螺旋进步的产物
对于微软为什么要推出ASP.NET MVC，我们是无从得知的，也许是因为JavaEE平台上有Struts，也许是因为MVC太流行，也许微软是想使得自己的Web App平台更完善，总之我们只能猜测。但是如果回顾一下微软的Web App平台进化过程，还是很有意思的。
ASP——微软最早为Web开发做出的贡献可能就是ASP了，这个动态语言把动态网页开发的难度空前降低了。但是，在很多人兴奋的用ASP写着一个又一个动态网页时，它的缺点渐渐暴露：语言过于简单，没有面向对象支持、没有好的IDE支持、动态脚本和静态HTML杂糅在一起，使得修改及维护极为困难。
Web Form——说实话，即使是用现在的眼光看，微软推出的Web Form编程模型确实是很有创意，也很实用。微软开创性地将桌面应用的开发模式引入Web应用开发：拖控件、写事件处理、运行...一切都那么美好，而且前段静态代码和后端程序完全隔离在两个文件里，并且用户可以使用.NET平台上任意一种语言进行后端编程。对程序员来说，使用C#进行编程比使用ASP实在是舒服太多了。所以，Web Form模型可以说成为.NET Web App开发的代名词，所有基于.NET平台的Web开发人员都熟悉并接受了这种模型。
ASP.NET MVC——就在Web Form大行其道时，微软推出了ASP.NET MVC。严格说，ASP.NET MVC和Web Form是不具有可比性的，Web Form是一个完整的新型模型，从顶层到底层是一整套的东西，而ASP.NET MVC只是给Web Form穿了件MVC样子的外套，它应该是基于Web Form的一种编程方式模型扩展。但是，从开发人员看，ASP.NET MVC的推出确实大大改变了我们的开发方式，很多Web Form下的方式不被提倡了（你仍可以用，因为ASP.NET MVC也是基于Web Form的），例如，曾饱受赞扬的服务器端控件再度被抛弃，转而再次使用客户端控件，事件驱动模型被抛弃，转而使用了类似传统的Url跳转处理模型。而且在数据验证等方式上与Web Form下提倡的方式有了很大变化。
如此看来，真像是一个轮回，似乎ASP.NET MVC又把我们带回到了ASP时代：服务器端模型不让用、事件驱动机制不让用、类似Desktop App的开发方式不让用...我们似乎从Web Form回到了传统的ASP时代。但是，真的是这样吗？当然不是！
只要稍微用一下，就知道虽然ASP.NET MVC提倡我们废除Web Form下的很多东西和习惯，但是绝不是让我们“回归原始”，如果非要说是一个轮回，那也应该说是一个螺旋式的轮回，是上升式的轮回。
记得马克思主义哲学中有个很经典的命题：对于新事物来说，道路是曲折的，前途是光明的。也许，Web App模型的发展就印证了这个观点吧。也许，服务器端控件、事件驱动模型这些东西一开始就是不适合Web App的，微软走了很多弯路，现在找到了正确的方向。抛弃的痛苦的，我们要抛弃曾经认为多么习惯并且倾注了大量心血的东西，但是，事物被否定后，剩下的的一个蜕变出的新事物，是一个更优秀的东西。
例如，我们抛弃了用了多年的务器端控件、事件驱动模型……但是我们得到了低耦合的、关注被分离的、符合MVC模型的新的Web模型。要敢于否定，才能获得新生。微软是，我们也是。
ASP.NET MVC带来的变化
下面，我们看看ASP.NET MVC到底让我们否定什么？又能得到什么。
1.服务器端表单控件。
由于ASP.NET MVC的特质，服务器端的表单控件不再被提倡使用，例如我们的文本框，不再使用asp:TextBox，而是使用传统的input，或直接让Html.TextBox生成。总之，很多服务器端控件被我们废止了。甚至GridView这样曾给我们带来无限快感的老朋友，也不再被提倡使用。但是，并不是说不能用任何服务器端控件，例如，为了实现母版，我们的ContentPlaceHolder还是必须要使用的。
2.事件驱动模型。
既然服务器端表单控件已经不提倡使用了，事件驱动模型自然也不被提倡，两者本来就是相辅相成的。在ASP.NET MVC中，当某个按钮被点击，你不要再习惯性想到应该在相应的aspx.cs中有个时间处理方法，你应该想到的是该有某个Controller中有个Action来处理这个事件。实际上，在ASP.NET MVC中，提倡不要在aspx.cs中写任何逻辑代码。甚至应该当他们不存在。
3.数据绑定
对于列表式表格数据，你一定习惯了GridView的数据绑定，可是，从你使用ASP.NET MVC开始，这不在被提倡了。你应该自己处理数据的显示。当然，我们也可以期待未来的ASP.NET MVC正式版中会有一个强大的Helper来帮我们做数据显示。
ASP.NET MVC的收益
你一定想知道，我们为使用ASP.NET付出了如此惨烈的代价，那么我们能得到什么？从我个人认为，你至少得到了以下东西：
1.清晰的、关注被分离的代码；
2.更容易的测试及维护；
3.更符合MVC的表示层；
4.你可以向Java程序员自豪的说：我现在也用MVC模式了，而且不用写任何XML！
总结
好了，到这里，这个系列就结束了。
在这个系列开篇里，我曾经说，我做这个系列的唯一目的只是让还徘徊在ASP.NET MVC门外的朋友快速入门，快速上手，快速学会使用这个框架做应用，所以，这个系列一直是在“实用”的指导思想下写的。它不够全面，没有涉及到ASP.NET MVC的方方面面。但是，我相信现在你已经有能力去自己学习那些“方方面面”了。当然，它也不够深入，没有讲解底层的原理。但是，现在的你一定也可以随着实践经验的基类，慢慢去研究它的原理了。
总之，只要你能通过这个系列的文章，学会使用ASP.NET MVC的基本方法，并已经开始试着做Demo了。那么，我的目的也就达到了。
写这篇文章的目的，是想总结一些东西，以帮助朋友们更好的使用这个框架。但是，我又不像把官方列举的哪些优势、功能翻译过来列举在这里。所以，我想干脆我就纯从个人观点上对这个框架评论一下吧。说的不好的，不对的还请批评指正。
ASP.NET MVC——螺旋进步的产物
对于微软为什么要推出ASP.NET MVC，我们是无从得知的，也许是因为JavaEE平台上有Struts，也许是因为MVC太流行，也许微软是想使得自己的Web App平台更完善，总之我们只能猜测。但是如果回顾一下微软的Web App平台进化过程，还是很有意思的。
ASP——微软最早为Web开发做出的贡献可能就是ASP了，这个动态语言把动态网页开发的难度空前降低了。但是，在很多人兴奋的用ASP写着一个又一个动态网页时，它的缺点渐渐暴露：语言过于简单，没有面向对象支持、没有好的IDE支持、动态脚本和静态HTML杂糅在一起，使得修改及维护极为困难。
Web Form——说实话，即使是用现在的眼光看，微软推出的Web Form编程模型确实是很有创意，也很实用。微软开创性地将桌面应用的开发模式引入Web应用开发：拖控件、写事件处理、运行...一切都那么美好，而且前段静态代码和后端程序完全隔离在两个文件里，并且用户可以使用.NET平台上任意一种语言进行后端编程。对程序员来说，使用C#进行编程比使用ASP实在是舒服太多了。所以，Web Form模型可以说成为.NET Web App开发的代名词，所有基于.NET平台的Web开发人员都熟悉并接受了这种模型。
ASP.NET MVC——就在Web Form大行其道时，微软推出了ASP.NET MVC。严格说，ASP.NET MVC和Web Form是不具有可比性的，Web Form是一个完整的新型模型，从顶层到底层是一整套的东西，而ASP.NET MVC只是给Web Form穿了件MVC样子的外套，它应该是基于Web Form的一种编程方式模型扩展。但是，从开发人员看，ASP.NET MVC的推出确实大大改变了我们的开发方式，很多Web Form下的方式不被提倡了（你仍可以用，因为ASP.NET MVC也是基于Web Form的），例如，曾饱受赞扬的服务器端控件再度被抛弃，转而再次使用客户端控件，事件驱动模型被抛弃，转而使用了类似传统的Url跳转处理模型。而且在数据验证等方式上与Web Form下提倡的方式有了很大变化。
如此看来，真像是一个轮回，似乎ASP.NET MVC又把我们带回到了ASP时代：服务器端模型不让用、事件驱动机制不让用、类似Desktop App的开发方式不让用...我们似乎从Web Form回到了传统的ASP时代。但是，真的是这样吗？当然不是！
只要稍微用一下，就知道虽然ASP.NET MVC提倡我们废除Web Form下的很多东西和习惯，但是绝不是让我们“回归原始”，如果非要说是一个轮回，那也应该说是一个螺旋式的轮回，是上升式的轮回。
记得马克思主义哲学中有个很经典的命题：对于新事物来说，道路是曲折的，前途是光明的。也许，Web App模型的发展就印证了这个观点吧。也许，服务器端控件、事件驱动模型这些东西一开始就是不适合Web App的，微软走了很多弯路，现在找到了正确的方向。抛弃的痛苦的，我们要抛弃曾经认为多么习惯并且倾注了大量心血的东西，但是，事物被否定后，剩下的的一个蜕变出的新事物，是一个更优秀的东西。
例如，我们抛弃了用了多年的务器端控件、事件驱动模型……但是我们得到了低耦合的、关注被分离的、符合MVC模型的新的Web模型。要敢于否定，才能获得新生。微软是，我们也是。
ASP.NET MVC带来的变化
下面，我们看看ASP.NET MVC到底让我们否定什么？又能得到什么。
1.服务器端表单控件。
由于ASP.NET MVC的特质，服务器端的表单控件不再被提倡使用，例如我们的文本框，不再使用asp:TextBox，而是使用传统的input，或直接让Html.TextBox生成。总之，很多服务器端控件被我们废止了。甚至GridView这样曾给我们带来无限快感的老朋友，也不再被提倡使用。但是，并不是说不能用任何服务器端控件，例如，为了实现母版，我们的ContentPlaceHolder还是必须要使用的。
2.事件驱动模型。
既然服务器端表单控件已经不提倡使用了，事件驱动模型自然也不被提倡，两者本来就是相辅相成的。在ASP.NET MVC中，当某个按钮被点击，你不要再习惯性想到应该在相应的aspx.cs中有个时间处理方法，你应该想到的是该有某个Controller中有个Action来处理这个事件。实际上，在ASP.NET MVC中，提倡不要在aspx.cs中写任何逻辑代码。甚至应该当他们不存在。
3.数据绑定
对于列表式表格数据，你一定习惯了GridView的数据绑定，可是，从你使用ASP.NET MVC开始，这不在被提倡了。你应该自己处理数据的显示。当然，我们也可以期待未来的ASP.NET MVC正式版中会有一个强大的Helper来帮我们做数据显示。
ASP.NET MVC的收益
你一定想知道，我们为使用ASP.NET付出了如此惨烈的代价，那么我们能得到什么？从我个人认为，你至少得到了以下东西：
1.清晰的、关注被分离的代码；
2.更容易的测试及维护；
3.更符合MVC的表示层；
4.你可以向Java程序员自豪的说：我现在也用MVC模式了，而且不用写任何XML！
总结
好了，到这里，这个系列就结束了。
在这个系列开篇里，我曾经说，我做这个系列的唯一目的只是让还徘徊在ASP.NET MVC门外的朋友快速入门，快速上手，快速学会使用这个框架做应用，所以，这个系列一直是在“实用”的指导思想下写的。它不够全面，没有涉及到ASP.NET MVC的方方面面。但是，我相信现在你已经有能力去自己学习那些“方方面面”了。当然，它也不够深入，没有讲解底层的原理。但是，现在的你一定也可以随着实践经验的基类，慢慢去研究它的原理了。
总之，只要你能通过这个系列的文章，学会使用ASP.NET MVC的基本方法，并已经开始试着做Demo了。那么，我的目的也就达到了。
