本文首发 http://blog.codepubs.com/archives/130 转载请注明出处

      记得某次面试的时候面试官问了我这样一个问题：“谈谈你对viewstate的理解。”

而我当时的回答是：“我很少用viewstate，一般情况下我都是选择禁用viewstate”

至于我这个回答面试官是否满意，以及对我的面试结果是否产生什么副作用我就不得而知了！ 今天我们就来谈谈这个 viewstate.

      最近换了工作，进来之后在一周的文档阅读与系统熟悉的情况下就开始正式参与到编码工作了。虽然我本人水平也不咋滴，但是我在以往的工作经验中都会尽量的做到更好，我经常会去逛逛技术博客，比如csdn、cnblogs、51cto 什么的，看到好的文章我一般都是收藏并加以仔细阅读，我这人有一毛病，看到好的东西并且是实用的东西我会记在心里，并且去应用，去实践。所以工作两年来，我的能力在不断的得到提高。以至于毫不夸张的说，也许我是个算法白痴，但是在产品体验以及基础性能方面我甚至超越了一部分比我工作时间长的人，当然工作这么点时间，我也没有遇到什么要求高深算法的项目。这个问题说到底其实也是态度所决定的。

        有一次有个同事问我：“你觉得对于程序开发知道怎么用重要，还是知道为什么这样用更重要。”而我的回答是：“我又不搞科研，在能够解决工作难题的情况下我知道怎么用就可以了”。没错，我确实是这样回答的，我不搞科研，我不必天天没事干去研究什么算法，因为那些用不到。就好像我们上学时候学的物理、化学一样。如果毕业后从事软件开发的行业，这些根本用不到（教育的悲哀）。

       上一段话和本文的主题有点冲突了，我说我只管知道怎么用，但是不去深究为什么会这样用，不过需要说明的是，本文只是针对于初学者，以及系统那些必要的优化。so….本文讨论的是很细微的，我们可以去规避的性能问题。

      好像跑题了！好吧，我承认我思维混乱了，我承认我写文章的水平很烂（呵呵），我突然想起来这几天看到某位童鞋说过：“想当年上学的时候，作文一写几万字都不带思考的，现在写个用户手册（如果我没记错的话）都累得慌！”

      写本文的起因也是源自我手头上正在进行的项目。目前我暂且不讨论架构以及数据库设计的问题。这篇文章的初衷是针对初学者能有一个提高。最起码是最基础的提高。

      第一、尽量减少无用的回发次数，看图：

如上图，红色细线框起来的 超链接“编辑”，暂且不去讨论这个列表是用的 GridView还是Repeater。

       这个编辑的实现是生成一个连接到 edit.aspx 页面，并且传一个参数过去。看看目前的实现：

ASPX：

   <img src="../images/edt.gif" width="16" height="16" align="absmiddle" />

     <asp:LinkButton ID="lbtnEdit" runat="server" CommandArgument='<%# Eval("EDR") %>' CommandName="Edit">编辑</asp:LinkButton>

CS：

protected void repEmployeeInfo_UserInfoCommand(object source, RepeaterCommandEventArgs e)
{
    if (e.CommandName == "Edit")
    {
        string id = e.CommandArgument.ToString();
        Response.Redirect("EmployeeInfoEdit.aspx?id=" + id);
    }

以上可以修改为直接在 ASPX 页面这样写：

<a href='EmployeeInfoEdit.aspx?id=<%# Eval("EDR") %>'>编辑</a>

解释一下这样写有什么好处：

         这是一个 客户端的 html a 标签，大家知道 aspx 页面经过 解析最终呈现到客户端的 还是 html 标签，那既然都是html 标签，为什么还要让 IIS 再去解析一遍呢？不觉得累赘么？

IIS 不但要把 <asp:LinkButton 解析成 html a  标签，还要 通过 commandName 把 a 标签的 连接 解析成  href……

上边那个删除我就不说了，如果是我，我仍然是写个 a 标签，到别地去删除，或者是 ajax 删除。当然有时候为了方便也是直接在页面上这样写的！这个可以这样写。毕竟是 .NET 控件的优势！     本文首发 http://blog.codepubs.com/archives/130 转载请注明出处

         第二：尽量减少页面大小

关于减少页面大小的问题，其实这个终归是返回到ViewStates上了！如果当前页面需要交互。而你又懒，非得用服务器控件，那是没办法了。但是我们可以针对 viewstate 进行压缩吧！压缩令谈，现在说说 关于 服务器控件选择的问题、

        比如我们现在有这么一个需求，查询出来数据，需要在页面显示（仅仅是显示），一般情况下，大多数人都会选择 Label 控件吧！为什么呢？因为用习惯了！就是不知道大家有没有发现 label 控件会在客户端生成一个 span 标签，而这个span 什么用处都没有。（别告诉我这个可以重写，现在不讨论这个问题），当然一个页面也不可能有N多个足够让页面体积大到不行的label，这里只是提到这个细节，细节。其实我们完全可以用  <%= %>去在页面显示数据吧，最不济，用Literal 也可以啊。他不会在客户端生成无用的垃圾代码（小心影响css效果）

       在现有项目（b/s web 对外 项目）中我仍然能够发现 通过隐藏显示 panel 来实现的一些效果。这简直。。。，在现如今 jquery 这么通用的情况下我们可以选择使用jquery达到这些效果。 

      我要提一点出来，在不用交互只是单纯显示数据的页面，请不要用服务端控件，请关闭 viewstate ，若页面需要交互也请尽量考虑别的解决方案（内部项目除外）

     真的真的，我已经语无伦次了，当我发现整个项目中全是.NET服务器控件完成的各个功能的时候我真的内伤了！（外网项目）

         第三：关于数据绑定控件的选择

大家都知道.net中有N多个数据绑定控件，估计最常用的也就是 列表控件了吧！我就挑选2 个来说：GridView 和 Repeater.

         首先谈谈GridView 和 Repeater 的优缺点：

        GridView 比较强大，该有的功能他都有了。分页，编辑，神马的。。但是他有个缺点，就是 如果禁用了 ViewState 他貌似就只能显示数据了。。而且生成垃圾代码较多。个人玩玩还可以。要遇到对性能要求比较高的bs 项目还是算了！况且如果禁用的 viewstate .gridview 就成了鸡肋了。

          Repeater 相对 GridView 来说，他具有模版的灵活性，repeater 不会附带生成任何代码，完全靠模版去实现，可控性比较强。

       总之，个人玩，或者小型项目，内部项目用gridview都行，只要BOSS同意，但是要是发布到外网的项目。还是用 repeater。最起码样式容易控制，不会生成额外代码而增加页面体积。有时候页面体积太大网速再慢点，页面的加载速度影响还是蛮大的！

       当然，如果你做的项目不是自己用，而是用来忽悠客户，也可以用 gridview

我实在写不下去了。。。

最后再啰嗦一点，外网B/S项目的性能有时候不单纯是网速所能影响的。页面加载的快慢和很多东西有关系，最起码，这篇文章提到了页面体积。尽可能是减少页面体积也是 ASP.NET 网站优化的一部分！

     本文首发 http://blog.codepubs.com/archives/130 转载请注明出处