代码改变世界

ASP.NET MVC小论

2008-12-04 11:11  T2噬菌体  阅读(10438)  评论(53编辑  收藏  举报

前言
      ASP.NET MVC作为微软官方的.NET平台下MVC解决方案,自诞生起就吸引了众多.NET平台开发人员的眼球。在经历了漫长Preview后,上个月微软终于发布了其beta版。应该说,通过我亲身实践,我认为这个框架的设计还是相当优秀的,至少从易用性来说,ASP.NET MVC要优于Java平台上的Struts和Struts2。使用Struts实现MVC时,除了要写一堆ActionForm、Action和ActionResult外,最头疼的莫过写于各种xml映射配置文件。Struts2虽然不用再写ActionForm,并且降低了侵入度(其实Struts2和Struts关系不大,而基本可以认为是WebWork的后续版本),但是仍无法避免xml配置文件。
      ASP.NET MVC从一开始的设计思路就与Struts不同,它的映射是利用路由配置而非xml,从而大大降低了开发复杂度,并且比Struts要更直观,更容易上手。
      可是,这并不表明ASP.NET MVC就是尽善尽美的。在我实践的过程中,发现某些地方使用起来还是不太方便,在这里小小论述一下。不妥之处,还请各位尽情批评。

别扭的视图:能不能不要让我承担逻辑
      我个人认为,ASP.NET MVC第一个不太妥当的地方就是视图的实现。在这个框架中,视图是使用ASPX文件实现的。就呈现数据这一需求来说,ASP.NET MVC下一般性的做法是:控制器负责调用Model完成数据的读取,并将需要呈现的数据通过ViewData传递给视图,并选择某视图呈现。被选中的视图要负责将ViewData中相应的数据读取、分解,然后使用一定的逻辑语句将其呈现。
      这个方式,就要求视图中存在一定的逻辑语句,如将ViewData中数据转换成相应类型的类型转换语句;如果需要按照某一条件呈现不同内容,则需要分支语句;而常用的表格式数据呈现需要用到循环语句。于是,我们就会看到视图中充斥着各种<%%>、if、foreach等等的东西。
      当然,我不否认,良好的编写可以让这些代码整洁的出现在视图中。然而,在我的心目中,一个良好基于Web应用的MVC 框架设计,其视图是不应该存在任何可执行代码的,而应该是一个单纯的模板文件,或者说含有可替换标签的页面文件,就像PHP平台下的Smarty那样。至于视图中相应的可替换标签替换成什么内容,应该是控制器的责任。设计一套良好的标签模板,对数据、分支、循环等常见任务设置相应标签,我认为是更适合ASP.NET MVC的视图设计。一来,这样可以让视图真正“静态化”,更有利于逻辑和表示的分离;二来,美工可以更好的关注于仅包含html代码和标签的视图,而不用关注于可执行代码。

对Ajax的支持:仍然很不方便
      我们知道,现在在一个Web应用中加入Ajax元素是司空见惯的,微软当然知道这一点,所以在ASP.NET MVC中,天然支持ASP.NET AJAX和jQuery,并提供了一个AjaxHelper来完成一些辅助性操作。然而,这个AjaxHelper的功能真是远远不够。
      由于ASP.NET MVC的特性,导致某一个Action的Url不是固定的。所以在请求Action时,一般不是将Url硬编码在页面中,而是通过Html.ActionLink动态生成。这就出现了一个问题,Ajax请求怎么办?当然,对于点击链接或提交表单触发的Action,AjaxHelper有专门的辅助方法,但是,如果某个Ajax请求不是通过链接或表单触发的,就会很有问题。毕竟你不能把Url硬编码在js里。
      关于这个问题,没有太好的解决方案,目前只能用一些类似hack的方式。如将Url用Html.ActionLink写入某个span,再将这个span的display设为none。最后,js从span中读入Url进行请求。
      希望在后续版本中,ASP.NET MVC能对Ajax有更好的支持。

文档
      再一个我认为ASP.NET MVC不太理想的地方就是没有完整的配套文档。目前能找到的官方文档只有Quick Start,并没有完整的开发文档。也许是因为正式版还没有发布吧,希望配套文档能尽快推出。

后面的话
      虽然有以上诸多不便,但是ASP.NET MVC作为一个正在发展的框架,我个人还是很看好其前景的。希望它能越来越完善,给ASP.NET平台上的MVC开发带来更多的便利。