为WebForms说几句话和一些ASP.NET开发上的经验（2）(2)

Repeater是ASP.NET 2.0中我最喜欢用的控件，它的功能很简单，把ItemTemplate和AlternatingItemTemplate的内容返回生成在页面上，并且将HeaderTemplate和FooterTemplate的内容显示在头尾。除此之外——没了。但是这已经足够了，对于绑定控件来说，还需要什么呢？这里面每一行代码都由我们自己编写，想定义样式也易如反掌，我们对于HTML的控制没有任何损失。

另外，有些开发人员总认为ASP.NET中的DataTable绑定的方式让我们无法写出建模良好的代码。就算使用ObjectDataSource，在控制上也会有诸多不便。但这个也是一种误解，我们完全可以将领域模型中的对象绑定到视图里的控件上。首先是ASPX的内容：

<asp:Repeater runat="server" ID="rptItems">
<HeaderTemplate>
<ul>
</HeaderTemplate>
<ItemTemplate>
<li>
<img src="<%# this.GetImagePath(Container.DataItem) %>" 
alt="<%# Eval("Title") %>" />
</li>
</ItemTemplate>
<FooterTemplate>
</ul>
</FooterTemplate>
</asp:Repeater>

然后是Code Behind：

public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
this.rptArticles.DataSource = this.GetArticles();
this.rptArticles.DataBind();
}
protected string GetImageUrl(object dataItem)
{
return "http://img.jeffz.net/" + (dataItem as Article).ImagePath;
}
} 

GetArticles方法的返回值可以是List<Article>或任何一个实现了IEnumerable<Article>接口的类型，这个样在ItemTemplate中访问Container.DataItem就会得到这个Article对象。我们在Code Behind类里定义一个protected方法，由于aspx最终会被编译为Code Behind类的子类，因此我们就可以在ASPX页面中调用GetImageUrl方法。在方法内部我们可以将object类型的DataItem转换成Article类型的对象，然后就可以做任意的处理了。

非常方便，非常灵活，还有什么可挑剔的呢？

有。比如我们想要使用每行10个元素，最后一行如果不足就让右边空着的方式来展示，Repeater可能就难以实现了（其实不能这么说，按标准应该还是使用无序列表，用样式来进行控制，Repeater完全够用）。ASP.NET 1.1和2.0可能我们会使用DataList控件，只要把RepeaterColumns属性设为10即可。可惜DataList生成的元素要么是<table />，要么是<span />和<br />，让人头疼。但是在ASP.NET 3.5中又多了一个ListView控件，使用这个控件进行展示可以分组循环，可以指定容器，真可谓无比强大。重要的是ListView和Repeater一样，所有的HTML都由自己控制，一个多余的字符都没有。

有了Repeater和ListView，真可谓打遍天下无敌手，任何页面的展示方式都不在话下。

我们再走个极端吧！我们来看下面的呈现方式：

<ul> <% foreach (Article article in this.GetArticles())
{ %>
<li>
<img src="<%= "http://img.jeffz.net/" + article.ImagePath %>"
alt="<%= article.Title %>" />
</li>
<% } %>
</ul>

上面的例子在ASPX页面中使用了内联的foreach语句进行显示。这样生成代码无论从干净还是自定义角度来说，都可以的让任何开发方式“无地自容”。但关键是，这个方式……为什么……恩，没错，说的难听，这是原始的ASP的开发方式；说的好听，这是“先进”ASP.NET MVC框架中模板的写法。这是不是很讽刺？但是这个的确是事实。Rick Strahl大牛也在他的Blog中写到：“我还记得在早些时候，那些ASP.NET的疯狂追随者们是多么不屑使用内联的脚本标签，或者使用显式的URL而不是PostBack来进行开发的做法，而其中的一些人现在又毫不犹豫地张开双臂去迎接MVC框架，这难道不讽刺吗？”而且由于ASP.NET MVC的特性（从Controller传递到View的只是一个ViewData对象），因此真正ASP.NET MVC的“模板”的写法还要多一次Cast，也就是类似于如下的写法（当然ASP.NET MVC可以使用强类型的ViewData，这样就免去了这样强行的Cast）：

<ul> <% foreach (Article article in (ViewData["Articles"] as List<Article>))
{ %>
<li>
<img src="<%= "http://img.jeffz.net/" + article.ImagePath %>"
alt="<%= article.Title %>" />
</li>
<% } %>
</ul>

这里就要谈到ASP.NET MVC了。其实光从View上来看，我不知道这算不算是进步（当然其实我不介意内联的写法，有时候反而更清晰）。ASP.NET MVC如果光从View（模板）方式来看，有点回到了当年的ASP方式（当然，还是补充了一些Helper）。ASP.NET MVC的特点在于M-V-C的分离，在于业务逻辑的触发方式，在于URL Routing的驱动方式，而不是模板化的写法。如果要说MVC在View层面比ASP.NET清晰，我是肯定不会同意的，因为我完全可以在WebForms的ASPX页面中“写成”ASP.NET MVC类似的方式。不知道您是否同意，至少我认为，使用WebForms内Repeater或ListView的写法，不会输给ASP.NET MVC的模板。而且事实上，在ASP.NET MVC中作为View使用的aspx页面里，我们完全也可以放置Repeater，然后再Page_Load方法里写代码，这更证明了，在View方面WebForms和ASP.NET MVC其实是非常相似的。

刚才说了，ASP.NET MVC的重要特点，在于M-V-C之间的分离，非常清晰，而且Model和Controller之间能够进行独立的测试。但是WebForms也可以做到这一点，我在后面的文章中还会谈一下WebForms里如何使用MVC来做到清晰、分离和单元测试等等。而且，我似乎觉得某些WebForms中能够做到的东西在MVC框架里却无法或者很难实现。可能是我对于MVC的了解程度还不够多的缘故吧，等我先研究了MVC框架之后再说。

讲到这里，您心中是否有了答案，WebForms究竟能否写出清晰美观的HTML？在WebForms控制样式是否困难？抛弃GridView，我们并没有什么损失，因为现在的网页中又有多少会用到GridView的功能呢？

目前老赵在公司使用WebForms开发时会与一个专职的前台开发人员配合。他是我认识的最好的前台开发人员，编程能力强，经验丰富，对于各种浏览器中脚本和样式的差异和问题可谓了如指掌，只是在这之前他只用过PHP，并没有接触过ASP.NET WebForms。但是仅仅向他解释了几个控件生成HTML的方式，或者如何从服务器端获得ClientID之后，我们之间的配合就非常轻松顺畅了。无论是开发人员先写放控件然后由他进行修饰，还是他先写静态样式页面我们再进行替换，都工作的非常顺利。我现在已经能够专注于业务的实现，架构的设计，而彻底从页面样式的“泥潭”中解放了出来，最多编写一下简单的JavaScript代码。分工的明确，也使得我们的工作效率得到了相当的提高。

所以最后我给大家的建议就是，尽可能地使用“纯粹”的服务器端控件。例如使用Repeater和ListView，其实写出优秀的页面非常容易。当然，即使这么做，还是会有一些缺点的，例如Repeater的ItemCommand事件已经无法使用了，因为它会用到ViewState。但是我们开发的大部分的页面甚至连PostBack都不需要，这又有什么关系呢？

使用服务器端控件虽然能让我们对于HTML有十足的控制，但是我们无法避免在客户端生成一个不规则的ID。这一点理论上可能会影响页面样式的开发，但是就我那前台开发人员同事的话来说，除了一些在客户端进行布局的DOM元素之外，几乎不会使用ID来控制样式。就我们工作的结果来看，不规则的ID也并没有造成任何的影响。