2008/5/10日，微软（西安）.NET俱乐部成立聚会和Visual Studio 2008 社区发布全国巡展在西安成功举办，我们这次活动参加人数非常多，以致我们的资料都不够发。同时我们也得到一些公司和个人对我们俱乐部活动的支持和肯定，其中活跃网络和葡萄成公司也希望我们俱乐部的活动以后能和他们共同研究技术等。

我坚信，只要我们一起努力，我们一定可以把我们西安.NET俱乐部办的更好。为此，我申请加入微软.NET俱乐部（.NET User Group），而且微软很快就批准了我们加入微软.NET俱乐部（.NET User Group）组织。

下面是来自微软批准我们通过的邮件部分内容：

Dear gao haidong:

CONGRATULATIONS! Your group (Microsoft .NET Xi’an Club) has been approved to be an INETA member based on your dedication to the .NET user group community. Welcome to INETA! If you have any questions about the goals of INETA, or if I can personally be a source of encouragement and information for you, do not hesitate to drop me an email!

    有人会问，我们加入微软.NET俱乐部（.NET User Group）组织有什么好处呢，好处当然有了，我们的活动，都可以请微软的讲师来讲课，而且微软给我们提供最新的技术资料以及一些礼品等等。

    在接下来的日子，我们草拟了一份俱乐部的章程，目前正在修改当中，目前我们主要在博客园作为我们的官方网站。活动信息都在这里发布。

俱乐部服务项目目前构想如下：

（以下服务项目均遵循自愿参加的原则）

       培训项目

 活动细则：定期对会员进行需求调查，根据调查结果确认主题并邀请主讲讲师。做到课程有针对性与实效性，竭力满足大多数会员的要求。

    活动形式：公开课

 活动资源：以微软的资深讲师作为主要师资力量，俱乐部中的相关领域的权威作为主要讲师，或根据情况邀请各高级培训机构的经验教师授课

       咨询研讨会

 活动细则: 搜集会员的疑难问题，对于问题进行分门别类，举行专门性的研讨会议。使会员在相互的交流中，开拓视野，不断提升。

    活动资源：邀请来自微软、IT企业或高校的技术骨干或专家作为顾问，主持会议。

                 交流和联谊活动

 活动细则：俱乐部将不定期地举办各种联谊活动，加强会员之间的沟通和联系，促进信息的流动和共享。

    活动形式：茶话会、体育活动等

    活动资源：所有的俱乐部成员均可参与

（以下服务项目均遵循个人申请、组织选拔的原则）

       项目开发

 活动细则：俱乐部会对外和对内进行软件外包的承接，用以给成员提供实践和锻炼的机会

    活动形式：集中开发、分散开发等

 活动资源：根据实际情况，利用成员个人或组织购买相应的设备；一些在开发技术、软件架构、项目管理方面能力突出的成员等

劳动报酬：凡是有营利的项目，除过成本，所有参与者均可根据其劳动情况获取相应报酬；没有盈利的项目，按其劳动付出的成本给予其在本组织的股份比例。

       图书翻译和书编写

活动细则：俱乐部会联系编辑社等，针对于.Net技术相关的外文图书资料等进行翻译和编写工作。

    活动形似：统一规划、分散翻译和编写，集中组合等

    活动资源：一些英文和技术均为突出的会员均可以申请参与。

 劳动报酬：凡是有营利的项目，除过成本，所有参与者均可根据其劳动情况获取相应报酬；没有盈利的项目，按其劳动付出给与其相应比例的股份。

以上内容欢迎个人朋友参与进来讨论，同时希望更多的人员能加入我们的俱乐部，想加入的朋友请写清自己的姓名、所在公司、项目经验、技术特长和联系方式等发邮件到ghd258@gmail.com，邮件主题请写明为“申请加入微软西安.NET俱乐部”。如果在博客园有帐号的朋友可以在http://www.cnblogs.com/ghd258/archive/2006/11/21/567609.html#1220947这里申请加入，注意写明自己的技术特长及联系方式等，最好能发邮件给我。

同时告诉大家一个好消息，上次聚会时说礼品有衬衫和扑克，但是当时扑克没有印好，衬衫当时被其他礼品代替。现在扑克已经印好了，而且已经到我这里了，由于大家平时都不在一起，等下次聚会的时候发给大家，不过要记得来参加活动哦！！！

本活动面向软件相关企业，以培训、交流、经验分享为核心，帮助从业经验在3～5年的软件技术人员（特别是软件测试技术人员）在技术思想、方法技巧等方面实现突破性提高，进而提高软件企业的技术和产品竞争力。本活动由微软资深专家顾问，曾就职于微软亚洲工程院的陆宏杰老师主讲，以实战的技术经验，深入讲解软件测试的4个最关键的方面，为您提供卓有价值的解决方案。

本次培训峰会内容围绕软件测试的主题，将会为企业及技术人员解决诸如以下的问题：

（1）    测试人员不足，特别是有经验的测试工程师不足；

（2）    没有有效的技术手段保证测试进度，甚至测试被认为是额外增加了项目进度、时间；

（3）    测试量特别大，测试报告不能及时反映最新版本中存在的问题；

（4）    测试中重复的劳动太多，长期下来，测试工程师缺乏成就感和创造力；

（5）    软件发布之前是否经历了足够测试了，能否发布到底谁说了算？

（6）    建立质量保证体系；

……

讲师介绍

陆宏杰

微软资深专家顾问，曾于微软亚洲工程院工作

曾任职于微软亚洲工程院，十余年的软件开发、软件测试和团队管理经验，曾主管过多个大型复杂项目的开发和测试工作，尤其在自动化测试技术和测试管理方面积累了大量的实战项目经验。对于各种测试方法的重点、难点和实施技巧有深入的研究，其主持开发和测试的项目多次获得微软全球最高技术奖项和工程奖项，并曾荣获msup2007 Top One金牌分享大师和msup2007 软件企业内训最佳好评讲师。

课程简介

麦思博（北京）软件技术有限公司

2008年3月17日

--------------------------------------------

联系方式

麦思博（msup）有限公司天津客服中心
联系人：马红伟
电话（Phone）：022.8371.8105-615
传真（Fax）：022.8371.8105-605
手机（Mobile）：13672160751
热线（Hotline）：800-818-8020
天津华苑产业园区华天道6号海泰信息广场H座402 （300384）

　　有了这些知识，你就知道该怎么做了，基本方法是隐藏的Input是一个textbox，我们要做的就是知道将来呈献的内容。一个TreeView最终呈现为HTML表格,节点的值被用来作为单元格的值,＜TD＞元素呈现节点名称,所以通过查找单元格ID并滚动到那里.

希望dudu让我放首页收集下各位朋友的意见 谢谢！！！

Adobe公司设计PDF文件格式的目的是为了支持跨平台上的，多媒体集成的信息出版和发布，尤其是提供对网络信息发布的支持。为了达到此目的， PDF具有许多其他电子文档格式无法相比的优点。PDF文件格式可以将文字、字型、格式、颜色及独立于设备和分辨率的图形图像等封装在一个文件中。该格式文件还可以包含超文本链接、声音和动态影像等电子信息，支持特长文件，集成度和安全可靠性都较高。

日常工作中经常遇到想把报表和网页导出到PDF的需求。本文提供完美的解决方案：

ASP.NET导出到PDF的最终效果图（其实winform和控制台程序都一样可以做）。

本文实现 文字，图片，数据表的导出
 核心技术方案：使用itextsharp.dll

1.下载itextsharp.dll和ICSharpCode.SharpZipLib.dll
http://sourceforge.net/project/showfiles.php?group_id=72954

iTextSharp.tutorial.01.zip    示例文件 提供了各种解决方案本文由于时间问题仅做抛砖引玉，希望大家自己研究其他需求

itextsharp.dll  itextsharp-4.0.3-dll.zip  

ICSharpCode.SharpZipLib.dll    http://download.csdn.net/down/135897  ICSharpCode.SharpZipLib.dll   

SharpZipLib.dll类库中的内容实现的压缩与解压功能，它是开源的

2.引用itextsharp.dll和ICSharpCode.SharpZipLib.dll

3.后台代码：

using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using iTextSharp;
using iTextSharp.text;
using iTextSharp.text.pdf;
using System.IO;
public partial class _Default : System.Web.UI.Page 
...{
    static DataTable datatable = new DataTable("testpdf");
    protected void Page_Load(object sender, EventArgs e)
    ...{
         //判断是否是回发页面http://blog.csdn.net/21aspnet
        if (!Page.IsPostBack)
        ...{
         DataRow dr;
        //建立Column例，可以指明例的类型,这里用的是默认的string
        datatable.Columns.Add(new DataColumn("编号"));
        datatable.Columns.Add(new DataColumn("用户名"));
        for (int i = 1; i < 5; i++)
        ...{
            dr = datatable.NewRow();
            dr[0] = System.Convert.ToString(i);
            dr[1] = "清清月儿" + System.Convert.ToString(i);
            datatable.Rows.Add(dr);
        }
        }
        
        
    }
    protected void Button1_Click(object sender, EventArgs e)
    ...{
       

        try
        ...{
            Document document = new Document();
            PdfWriter.getInstance(document, new FileStream(Server.MapPath("Chap0101.pdf"), FileMode.Create));
                        document.Open();
            BaseFont bfChinese = BaseFont.createFont("C:\\WINDOWS\\Fonts\\simsun.ttc,1", BaseFont.IDENTITY_H, BaseFont.NOT_EMBEDDED);
            Font fontChinese = new Font(bfChinese, 12, Font.NORMAL,new Color(0, 0, 0));

                        document.Add(new Paragraph(this.TextBox1.Text.ToString(), fontChinese));

            iTextSharp.text.Image jpeg = iTextSharp.text.Image.getInstance(Server.MapPath("pic015.jpg"));
            document.Add(jpeg);
            PdfPTable table = new PdfPTable(datatable.Columns.Count);

            for (int i = 0; i < datatable.Rows.Count; i++)
            ...{
                for (int j = 0; j < datatable.Columns.Count; j++)
                ...{
                    table.addCell(new Phrase(datatable.Rows[i][j].ToString(), fontChinese));
                }
            }
            document.Add(table);

            document.Close();
        }
        catch (DocumentException de)
        ...{;
            Response.Write(de.ToString());
        }
    }
}

4.前台代码：

<%...@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>清清月儿 制作导出PDF http://blog.csdn.net/21aspnet</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
        <asp:Button ID="Button1" runat="server" OnClick="Button1_Click" Text="导出" /></div>
    </form>
</body>
</html>

5.前台操作：

 6.属性说明：

itextsharp-4.0.3-dll.zip   示例文件包含几乎所有的PDF处理需求

颜色：

项目的需要变化是肯定有的，而且变化一般都很频繁，我们怎么应对客户的这种需求变化呢，以不变应万变。首先在前期的需求调研要做好，尽可能的替用户考虑，达到功能质量满足最大化。需求调研前期的《目标与范围》和需求调研末期的《功能规格说明书》都要跟客户签字确认，这样既能保证我们所理解的需求就是客户所要的，也使得项目末期跟客户验收时有据可依。在项目中期是发生需求变更是很常见的，这时要做好需求变更管理流程。需求变更表，小的变更自己掌握，客户要求的变更有开发人员和设计人员共同商讨后提交项目经理，项目经理预估变更损耗工程时间，在一定阶段一起提交给客户，大的变更直接提交客户，并且要把需求变更对项目产生的影响让客户知道，把球尽可能的踢给客户，让客户在进度、功能、资源三者中取舍出一个平衡来。对需求进行分类评级，关键部分不能改动的做特别确认（如系统架构等，如果改变等于从头再来）。同时完成客户签字确认，当然如果能将这部分写成合同细节中去是最好。以下是我认为变更的步骤：

¢ 第一步：客户提出变更内容

l    客户提交的变更必须基于书面形式

l    客户提交的变更必须有充分理由

•   如果变更被拒绝，对业务的负面影响

•   如果变更被接受，对业务的正面帮助

¢ 第二步：为能否实现变更作评估

l    从实现方式上考虑新的变更可否实现

l    对于较复杂的情形，辅以简单的说明。欲详述，可作附件处理

l    对于简单情形，例如页面布局更改，则无须说明

¢ 第三步：可以实现看进度

l    进度几乎是绝大部分项目关注的第一要素

l    对于活动级别的进度影响

l    对于项目整体工期的影响

¢ 第四步：变更成本

l    人力相关的变更成本

•   是否需要额外的项目组成员

•   项目组需要增加的工时数

是否正常工时（工作日加班、节假日加班）

•   项目工数报价

l    非人力成本

•   软硬件费用

•   资料费用等

¢ 第六步：质量和风险

l    变更对质量的多方面影响

•   分阶段影响（需求、设计、编码、测试、维护）

•   可靠性、安全性、可维护性、可用性等

l    可能对团队士气的负面影响

l    可能引发的间接任务对工期的负面冲击

l    开发方的成本负担可能超出力所能及的范围

¢ 第六步：需求变化的确定

1.2      架构设计

撰写详细设计是一个逐步细化、深入的过程。没有人能一次就设计出完美的东西，需要及时的沟通，包括与客户的反馈，与其他项目组成员的讨论，这样有助于降低开发时偏离需求的风险。也就是说，在开发之前题，是建立在设计者的想法有客户的确认和开发人员的理解的基础之上设计撰写人必须与系统分析员反复讨论，以透彻理解用户需求；

一项需求可能有多种方式实现，设计者必须与系统分析员确定该需求将采用何种方式实现，将达到何种效果，以消除将需求映射为设计的歧义；讨论过程中还可能会发现需求有不完备甚至错误的地方，在需求重新确定后设计者需修正设计。设计文档必须写清楚各个模块/接口/公共对象的定义，列明程序的各种执行条件与期望的运行效果，还要正确处理各种可能的异常。此外设计文档应该遵循一定的写作模式与版面风格，使用统一的术语或惯用语，使得小组成员很容易理解。以上这些活动综合起来将是一个很细致、很耗时的工作过程。就个人所知，一些公司的详细设计通常是由程序主管或少数核心的程序员撰写的，他们通常也是系统架构的主要作者或维护者。因为他们在开发团队中技术最为精湛，对架构最为熟悉，他们最有资格评价现有架构是否能适应新的用户需求，采用何种方式实现需求对架构的冲击最小。但是由少数人来负责所有的详细设计可能造成开发过程中的瓶颈甚至是设计的错误。当任务比较集中的时候，设计者可能忙得透不过气，而负责实现的同事反而在等米下锅，比较清闲。于是为了让自己不成为拖累进度的“罪人”，某些设计者就会采用一种快捷方式来交付设计：他们会与系统分析员进行初步的讨论，然后撰写一份粗糙的但仍然叫做详细设计的文档，把它交付给负责实现的同事，再通过讨论、即时通工具、电子邮件等方式解答对方提出的疑问。但由于详细设计本身不完备，他们不得不花费更多的时间和精力与负责实现的同事沟通；而且他们却很可能忘了把这些交流的成果更新到详细设计中去！（或许是他们太忙，没有足够的时间，又或许是他们认为既然产品已经实现，那么详细设计也就不必维护了。）其结果很可能是当产品开发出来后，我们才发现它跟用户要求的完全两样！原本在详细设计阶段就应该发现的需求漏洞与在那时应该确定的技术方案在实现阶段甚至测试阶段才暴露出来，而这时大家往往有木已成舟的感觉，改动的难度比设计阶段高数倍甚至十倍以上，毕竟任何再牛的人都有自己的局限。
    对于以上问题我提出全员设计，全员设计的含义就是把详细设计的工作进行适当地分解，把它们分摊到小组内其它同事身上，让大家都参与设计。这可以说明如下：
    当一组用户需求基本确定下来后，程序主管需要估计需求的相关性、需求的优先级、设计的难易程度、设计的工作量等，将该组需求分解为一或多项设计任务，并指定给适当的同事。参与设计的每个人必须负责至少一项设计的撰写任务。设计者从系统分析员处获得详细的用户需求，并与系统分析员反复沟通以透彻理解用户需求。他还要分析系统架构及产品的已实现与/或已规划部分，理解架构的设计理念，理解产品不同模块之间的协作关系，理解架构与产品之间的约束和依赖。当然对系统架构和产品的分析不可能穷尽每一个细节，只要分析与即将开发的模块相关的内容即可。

一项设计任务，它可能需要多个程序员完成。比如用户界面或网页由某位或某组同事负责，而业务逻辑组件则由另一位或另一组负责，数据库部分则又由其它同事负责。设计者必须考虑他们的立场，以各方面都相对容易理解的方式写清楚主要的模块/接口/对象定义，明确相应的调用规则与主要逻辑处理。如果某项设计任务所涉及的内容太专业化，设计者并不熟悉相关的内容（比如某位C#程序员并不熟悉如何编写一个存储过程），他可以用描述性的文字说明该部分的设计要求，并知会相关的同事补充。其它同事在补充时可以对这些描述性的文字重新整理，以更加确切地表达设计内容，更符合文档的书写惯例。在设计文档完成后，设计者必须把他提交给程序主管或由程序主管指定的程序员审阅。个人推荐由其它程序员而不仅仅是程序主管来审阅。不用担心等待多个人的审阅意见是否可能导致一份设计滞留很久。大家可以并行地工作，不必是A审阅后才能B审阅。可以交叉审阅，即A的设计由B、C审阅，B的设计由A、C审阅等。审阅意见可以用多种方式（如讨论、即时通工具、电子邮件）反馈给设计者，设计者负责汇总这些意见并修正设计。以个人的经验而言，通常设计交付审阅后半天内就可以收到反馈意见了。设计经过反复地修正直至没有人再提出修正意见，这时就可以由程序员实现了。以个人的经验而言，一份设计通常两、三轮反馈后就可以定稿了。如果多次反馈后仍不能定稿，极有可能是：
a)需求尚未明确，各个方面（包括客户、系统分析员或设计者）对需求的看法不统一
b)技术或系统架构存在严重的限制，无法用较方便的方式实现

全员参与设计好处、风险与不适用的团队如下：

1.2.1 全员设计可以带来以下明显的好处

1.有助于平衡工作量，加快开发进度。详细设计的任务分解后，程序主管或核心程序员可以有更多的时间处理其它的事务，比如关注软件的开发质量或改善系统架构。详细设计的撰写任务分解后它们可以并行地撰写，这将极大地提高设计撰写的进度，节约时间。
    2.有助于培养程序员的大局观。每位撰写设计的程序员不再仅仅只关心自己负责实现的模块，他必须从更高的层次考虑和理解设计。
    3.有助于加强同事之间的交流与协作。设计者需要与系统分析员、其它程序员、审阅者进行反复的交流和沟通，实际上每份设计都是多人协作的成果。更多的沟通有助于集思广益，有助于避免一、两个人的倾向性意见导致错误的设计。每位设计者都需要对自己撰写的设计负责，他还要向其它同事的设计提供审阅意见或技术建议，彼此的工作是互相支持和依赖的，这有助于减少“只扫自家门前雪，不管他人瓦上霜”的想法。

1.2.2 推行全员设计的潜在风险

1.在某种意义上，全员设计可能增加交流的成本。两个人之间有一条交流途径，三个人之间最多有三条，四个人之间最多有六条。途径越多，信息量就越大，而这些信息不见得都是有用的信息。详细设计的任务分解后，不可避免地有更多的人参与交流和沟通，大家要花更多的时间来理解他人的想法，也可能要花更多的时间向他人阐述自己的观点。特别是在并行撰写详细设计的过程中，系统分析员反而可能成为另一个瓶颈了。但从总体上来看，在设计阶段花费适当的代价发现更多的问题，比在实现阶段或测试阶段再发现问题，仍然是划算的。
    2.分解后的详细设计可能引入冲突的设计内容。由于设计由不同的程序员撰写，他们考虑问题的角度和思维的方式不可能完全一致，这增大了不同的设计内容之间的计算口径或交互方式不一致的可能性。这需要设计者们尽可能遵循一致的设计原则，也需要审阅者们尽可能找到这些不一致的地方。
    3.并不是所有的程序员都适合参与设计。很明显，例如刚入职的同事就不适合参与设计，他们对系统架构还缺乏足够的认识。另外兼职的同事也不适合参与设计，他们的工作方式可能无法保证及时提交设计文档与参与讨论等。

1.3    沟通

 在项目的开发过程中，在团队中的成员之间以及和客户之间是一个不断的交流和沟通的过程。我们的开发过程最好是一个迭代式的开发过程（尤其是国内的项目）。这样我们可以尽早发现开发出来的功能是不是符合客户的需求，以免开发完了，客户说这个不是我们需要的后果。

1.4    计划执行控制

制定系统得整个计划，任务的划分以及分配工作，跟踪任务的进度，使我们的项目进度在控制范围之内。

1.5    风险管理

风险是随着项目的不同阶段变化的，不同的阶段风险是不同的，我们必须分析我们当前面临的风险的数量、影响程度等，以及怎么去解决这些风险。

1.6    测试

测试工作目前在国内的中小公司做的都不太好，但是从我们做项目或者产品必须重视测试工作，把握好质量关。

1.7    验收为目的的思想

在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，比如，【界面要求：美观大方、简洁明快】，这个要求我就不知道如何检查。所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划，里面有一个任务【开发人员熟悉EJB编程】，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。做项目就是为了验收，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。
项目开发经验谈（一）
http://www.cnblogs.com/ghd258/archive/2007/05/22/756102.html

根据我们项目出现的问题，我自己的总结的一些经验以及我在培训中学习得知识总结下项目中遇到的问题和解决方案。

1.1     签订合同

     项目的合同内主要写的很模糊，范围可大可小，致使在后期的工作中项目越做越大，但是项目费用是不变的。在国内的合同好像都是在打单时是基本上都承诺，也不会到细节，在合同签订后启动后才发现问题。但合同中可以写明如果需求变更什么级别的怎么样，多少钱等;签订合同也是一个很高的技巧，建议把系统的边界及功能范围和解决方案与合同一起签署，这样客户提出的新功能就可以暂且搁置。

1.2        团队建设

 在立项后尽早确定该项目的负责人及项目经理，这个人员非常关键，需要很强的综合能力，尤其的人格魅力方面。尽最大的努力将客户的人员加入到我们的项目团队来，这个人也是我们将来和客户的统一联系人，客户指定一个人和项目组进行沟通，不能是张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，项目组只认一个的意见，有什么要求你们内部先统一再和项目组谈，我们不想卷入客户内部业务部门之间的矛盾和政治斗争之中。很多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难有什么具体要求，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配备行业专家（Industry expert），这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。项目经理需要了解每个组员的情况，用就要用每个员工的特长。软件行业是个非常特殊的行业，从项目的管理以及人员的管理都有它的特殊性。

作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望值，让他们从理想回到现实也是项目经理的分内工作。

1.3     需求调研

在需求调研分析阶段，项目组对客户的整体组织结构、有关人员及其关系、工作职责等没有足够了解以致于无法得到完整需求或最终经权威用户代表确认的需求。由于项目经理和需求分析员的工作问题以及调研工作做的不够细，客户参与程度都不高，客户方相关责任人不明确或对范围和需求责任心不强，提出的需求具有随意性，项目前期对需求的确认不够积极；多个用户代表各说各话、昨是今非但同时又希望软件尽早交付；我们的做法主要注重领导的需求，基本上都是领导说什么就是什么，致使开发出来的功能在实际使用中不是真正的使用人所需要的，项目后期需求变化随意，造成项目范围的蔓延，进度的拖延，成本的扩大。同时在我们的认识中是需求调研很关键，很多公司只是概念上认为该阶段重要，需要投入的时间长，但是实际上很多公司做不到这个，总想很快进入编码阶段。而且为了赶进度总想省做某些工作，少写某些文档，使我们无法拿出客户需求以及后来功能变化和原先功能之间的对比度。

造成上述现象的原因是我们没有全面了解所有项目干系人的需求以及对需求调研的重视程度不够。软件开发是没有捷径可以走的，省掉的工作后面会有更高的代价回报。全面的需求来自所有项目干系人，不同的干系人其愿望和追求的目标往往相差甚远，因此对项目干系人的愿望进行平衡可能是相当困难的事情。

软件开发项目的目的就是实现项目干系人的需求和愿望。如果对项目所有干系人没有进行足够的沟通和影响，使其尽可能地参与项目，则可能因为项目开始时项目范围和一些具体需求不够完整清晰，也可能因为某个项目干系人后期因为认识的变化而提出新的需求，造成工期的延长，成本的增加，甚至项目的完全失败。因此，应当从项目的启动开始，需求分析员及其项目成员就要分清项目干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。以下是一些有效的措施

1、尽快熟悉项目干系人全貌
　　有些项目在做需求调查时，由于受进度要求等客观因素影响，需求分析员与建设单位的技术部门交流较多，向业务管理部门和实际使用者调查不够深入，造成软件试用后不得不再对需求做较大调整，"从头再来"的部分比例很高，大大超过进度要求时间。因此，熟悉项目干系人全貌是进行需求调查的第一步，也是需求调查的基础。在定制开发项目的项目干系人中，最重要的是建设单位中的人事组织、业务关系。最好是能够用组织结构图画出相关单位的组织结构；建立调研对象通讯录以保证调研及分析期间及时的沟通。与此同时要注意项目干系人的主次关系，以便在他们之间的需求出现矛盾时能够进行合理的取舍。
　　熟悉建设单位内部相关部门的业务划分及它们之间的相互关系,为功能分析准备了必要的资料, 同时可以熟悉用户方的各类人员，并及时进行广泛、有效的沟通与交流。特别要与客户方业务与技术的规划者和实际使用者进行深入探讨，收集必要的原始资料，保证需求调查的完整性、正确性。
　　建设单位只是项目干系人中的一部分（当然是主要的部分），为了更好地了解项目干系人全貌，还应当在建设单位组织结构图基础上全体项目干系人结构图，以便更好更全面地进行需求调研分析。
　　2、详细描述各项业务，以利于让所有客户确认
　　尽可能全面详细地调查并且描述原有系统（这点非常关键，需要调查清楚原有系统的不足以及优点，以及用户在这些系统中的操作习惯）和用户希望将来系统具有的各项业务的流程，并将这些业务流程文档化后与客户进行讨论，对描述错误或不准确不精确的进行修改，最终让客户进行确认。从个人认为，对业务处理过程了解的完整性和准确性非常重要。虽然对数据来说都是查增删改传，但具体业务都是分为若干步骤，每个步骤都有其业务名称，同一步骤可能对多个数据集进行不同操作，需要调查了解清楚才能设计出适合各流程业务节点用户业务特点和习惯的软件，使开发出来的软件更受欢迎。当然在进行软件概要设计时，要尽量排除业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，充分考虑他们与其他各种业务对象的接口，在流程之间通过业务对象的相互调用实现其业务流程，这样，在业务流程发生有限的变化时，就能够比较方便地修改系统程序而实现新的需求。
　　对于各项业务的调查可以通过对以下资料的收集整理分析，这些资料来自各种各样的项目干系人：遵循的标准、组织发放的工作手册、作业流程、有关业务的上级通知、有关业务的办事指南、办理业务时需要填写的登记表、各种相关的统计报表及通过其他途径收集的类似系统的介绍、技术资料等等。
　　3、可视化需求调研，引导各种客户挖掘他们的需求
　　很多客户因为自己缺乏计算机知识，无法提出完整准确、隐含的或潜在的需求。但若这些需求不能满足将导致用户的不满。因此需求调研分析人员应善于想用户所想，不要害怕用户的需求多，不但要确定明确的需求，还要善于用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。这就要求需求调研分析员要尽快完整地熟悉相关业务，从而能够站在用户的立场看待软件需求，想用户所想，做好业务与计算机之间的桥梁。利用可视化需求调研的方法可以很好地启发用户深入挖掘潜在的需求。可视化需求调研就是使用图表等工具来启发引导用户清楚地叙述需求，并且使需求更加全面完善。
　　对于高层领导，可以提供系统总体框架图；对于业务管理人员，可以用业务流程图来描述新旧系统的业务流程；对于客户中的技术人员，可以用数据流图、实体关系图或UML中的各种图形对系统进行各种角度的描述；而对于业务管理人员、客户中的技术人员、以及各层次各流程中的用户，画出用户界面图来进行需求挖掘，是个比较有效的沟通方式。
　　这里特别说明一下用户界面的重要性。用户界面的设计按理来说是软件设计的责任，当然客户自己对界面有特别提出要求的除外。但是，如果把它提前到需求调研时（紧接着原有系统调研分析和系统模型完成之后）与客户进行讨论，则可以大大改善需求调研的效果。因为这时客户对于将来的系统还没有一个形象上的概念，或者有一个模糊的预想的概念需要表述、验证、明晰化、完善化。从我们后来的项目先做界面和用户交流的经验看（系统原形应该在需求分析的时候开发人员在分析师的指导下完成真实环境中的开发，当然开发只是界面的功能模拟，没有底层代码的实现），画出用户界面草图与客户进行讨论，可以大大激发他们提供更为准确全面的需求，而且这些界面在后期的开发中也可以利用。原来收集资料，描述业务，说明系统模型到了山穷水尽的时候，这种方法可以达到柳暗花明又一村的效果。因此，所谓需求就是“当你按下各种相关按钮（或输入各种相关命令）时系统做什么”，所谓设计就是“当你按下各种相关按钮（或输入各种相关命令）时系统怎么做”。需求的最终目的实际上是完整准确地描述系统需要的各种接口或“界面”，及它们的相互关系或与外部环境的关系，如界面中的某个按钮按下去时，可能产生新的界面、新的按钮、或者调用其他软件硬件完成某些功能。自顶向下，把这些界面及涉及到的数据描述清楚，就是一份不错的需求。
　　4、与其他项目小组成员共同协作、持续完善系统需求
　　需求文档完成之后，并不是万事大吉，把它扔给后面的设计人员就了事了。作为项目干系人之内的项目组其他成员，对需求的有效性也起到某种程度的验证作用。虽然软件项目的生命周期按照各种开发模型有不同阶段的划分，但每个阶段的结束不是简单地把阶段工作成果塞给下一阶段的成员就可以了。特别是高科技的软件开发项目，上一阶段的工作成果往往要通过多次的沟通才能更为清晰地被下一阶段成员接受，其有效性、合理性也要被下一阶段的工作所检验，通过检验有时也有必要对上一阶段的工作结果进行相应的调整，需求更是如此。因此，无论是同一阶段不同人员之间，或是不同阶段人员之间都应根据需要相互协作，相互配合，共同完成软件开发任务

5、《功能规格说明书》，这个是我们项目中最大的失误，致使后来客户的改动让我们很被动。《功能规格说明书》反映了客户提出的所有需求功能，我们也是按照《功能规格说明书》来开发的。后期客户的变化都可以和《功能规格说明书》对比，具体怎么变更按照我们的变更流程来做。《功能规格说明书》作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并且不能在产品中出现。并且注意以下几点：

(1)完整性

每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用“待确定” 作为标 准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的“待确定”项。

(2)正确性

每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。

(3)可行性

每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。

(4)要性

每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。

(5)划分优先级

给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制

(6)无二义性

对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。

(7)可验证性

检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。
(8)一致性

一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实正确。
(9)可修改性
在必要时或为维护每一需求变更历史记录时，应该修订文档。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在文档中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。

 (10)可跟踪性

 应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。

        项目开发经验谈（二）
http://www.cnblogs.com/ghd258/archive/2007/06/04/771154.html
在项目开发总的一些感受
      http://www.cnblogs.com/ghd258/archive/2007/02/12/648697.html

    请申请加入“西安.NET俱乐部”的朋友贴一下你的联系方式,谢谢！
    Example:

    Blog名：ghd258        (注意，不要随便写一个名字，必须是注册成为 博客园 的会员名)
    MSN:    ghd258@hotmail.com 
    Email:  ghd258@hotmail.com 
    QQ:     14983030
    最感兴趣的研究方向：Asp.net、WebService应用

    请大家务必写一下自己感兴趣的方向，这样更方便大家找到方向相同的朋友，而且请一定要记得贴一个Email，活动的通知会主要以Email为主，希望大家先通过这个Blog团队的形式加入，先交流起来，谢谢你的配合！

 2核心对象模型设计

      根据RBAC模型的权限设计思想，建立权限管理系统的核心对象模型.对象模型中包含的基本元素主要有：用户（Users）、用户组（Group）、角色（Role）、目标（Objects）、访问模式（Access Mode）、操作（Operator）。主要的关系有：分配角色权限PA（Permission Assignment）、分配用户角色UA（Users Assignmen描述如下：

       a .控制对象：是系统所要保护的资源（Resource），可以被访问的对象。资源的定义需要注意以下两个问题：
       1.资源具有层次关系和包含关系。例如，网页是资源，网页上的按钮、文本框等对象也是资源，是网页节点的子节点，如可以访问按钮，则必须能够访问页面。
       2.这里提及的资源概念是指资源的类别（Resource Class），不是某个特定资源的实例（Resource Instance）。资源的类别和资源的实例的区分，以及资源的粒度的细分，有利于确定权限管理系统和应用系统之间的管理边界，权限管理系统需要对于资源的类别进行权限管理，而应用系统需要对特定资源的实例进行权限管理。两者的区分主要是基于以下两点考虑：
        一方面，资源实例的权限常具有资源的相关性。即根据资源实例和访问资源的主体之间的关联关系，才可能进行资源的实例权限判断。 例如，在管理信息系统中，需要按照营业区域划分不同部门的客户，A区和B区都具有修改客户资料这一受控的资源，这里“客户档案资料”是属于资源的类别的范畴。如果规定A区只能修改A区管理的客户资料，就必须要区分出资料的归属，这里的资源是属于资源实例的范畴。客户档案（资源）本身应该有其使用者的信息（客户资料可能就含有营业区域这一属性），才能区分特定资源的实例操作，可以修改属于自己管辖的信息内容。
        另一方面，资源的实例权限常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。
        b.权限：对受保护的资源操作的访问许可(Access Permission)，是绑定在特定的资源实例上的。对应地，访问策略（Access Strategy）和资源类别相关，不同的资源类别可能采用不同的访问模式（Access Mode）。例如，页面具有能打开、不能打开的访问模式，按钮具有可用、不可用的访问模式，文本编辑框具有可编辑、不可编辑的访问模式。同一资源的访问策略可能存在排斥和包含关系。例如，某个数据集的可修改访问模式就包含了可查询访问模式。
        c.用户：是权限的拥有者或主体。用户和权限实现分离，通过授权管理进行绑定。
        d.用户组：一组用户的集合。在业务逻辑的判断中，可以实现基于个人身份或组的身份进行判断。系统弱化了用户组的概念，主要实现用户（个人的身份）的方式。 
        e.角色：权限分配的单位与载体。角色通过继承关系支持分级的权限实现。例如，科长角色同时具有科长角色、科内不同业务人员角色。
        f.操作：完成资源的类别和访问策略之间的绑定。
        g.分配角色权限PA：实现操作和角色之间的关联关系映射。
        h.分配用户角色UA：实现用户和角色之间的关联关系映射。

 该对象模型最终将访问控制模型转化为访问矩阵形式。访问矩阵中的行对应于用户，列对应于操作，每个矩阵元素规定了相应的角色，对应于相应的目标被准予的访问许可、实施行为。按访问矩阵中的行看，是访问能力表CL(Access Capabilities)的内容；按访问矩阵中的列看，是访问控制表ACL（Access Control Lists）的内容。
数据模型图如下：

 希望各位多提意见 ,再完善

我们在编写基于 ASP.NET 的应用程序时，如果代码执行出错或检测到异常，一般会提示用户“返回”或“回退”，或者在多步操作、列表/详细的查看界面中，也会给用户提供回退到上一页面的链接，对于这种情况，大家很快就会想到的简单做法就是利用 Javascript 来实现，即 history.go(-1) ，但是由于 ASP.NET 页面的 PostBack 机制，所以 history.go(-1) 可能还是当前页面，而不能真正回退到上一页面。

在 Classifieds Site Starter Kit 中，学习到一种不错的关于回退的处理方法，可以分别在客户端和服务器控件中实现页面的回退，代码如下：

1）首先在页面中增加两个属性

    //记录上一个页面的信息
    private string UrlReferrer
    ...{
        get
        ...{
            return ViewState["UrlReferrer"] as string;
        }
        set
        ...{
            ViewState["UrlReferrer"] = value;
        }

    }

    //记录 PostBack 的次数
    public int NumPostBacks
    ...{
        get
        ...{
            if (ViewState["NumPostBacks"] != null)
                return (int)ViewState["NumPostBacks"];
            else
            ...{
                ViewState["NumPostBacks"] = 0;
                return 0;
            }
        }
        set
        ...{
            ViewState["NumPostBacks"] = value;
        }
    }

2）在 Page_Load 事件记录上一页面地址、更新 Postback 次数、设置回退链接的地址

    // 记录上一页面的信息或更新 PostBack 的次数
    protected void Page_Load(object sender, EventArgs e)
    ...{

        if (!Page.IsPostBack)
        ...{
            if (Request.UrlReferrer != null)
                this.UrlReferrer = Request.UrlReferrer.ToString();
        }
        else
            NumPostBacks++;

        int goBackSteps = NumPostBacks + 1;
        BackLink.NavigateUrl = String.Format("javascript:history.go(-{0});", goBackSteps);
    }

3）直接在代码中处理回退操作（如 Back_Click），可以直接调用如下方法

    //在代码中回退
    protected void ReturnToPreviousPage()
    ...{
        string referrer = UrlReferrer;
        if (referrer != null)
            Response.Redirect(referrer);
        else
            Response.Redirect("~/default.aspx", true);
    }

来自：http://blog.joycode.com/moslem/archive/2006/10/17/85307.aspx

1、The Freeze Pane DataGrid （http://www.codeproject.com/aspnet/FreezePaneDatagrid.asp）

利用文章中提到做法及代码，可以实现在 ASP.NET 1.1 上的、支持横向滚动与纵向滚动的表格，基本上是使用 CSS 实现的，比较简单。

在 ASP.NET 2.0 上，由于文档 HTML DOCKTYPE 发生了变化（HTML->XHTML），所以在使用原文中的横向滚动条会出现问题，但是使用纵向滚动条和锁定表头没有问题。

这种做法没有考虑页面 PostBack 时记录表格的滚动位置，使得用户不得不重新去寻找刚才选中/编辑的那条记录，这比较的不人性化。

2、ScrollingGrid: A cross-browser freeze-header two-way scrolling DataGrid（http://www.codeproject.com/aspnet/ScrollingGrid.asp）

此文章利用 Panel 控件和 DataGrid 控件实现了 ASP.NET 1.1 下的完整的、可实现双向滚动、表头锁定的表格，而且它实现了可以记录表格的滚动位置，页面 PostBack 后，表格仍能自动滚动到原有位置。这个控件的一个最大优点是能够适应多种浏览器，如 Internet Explorer 、FireFox 等。

在 ASP.NET 平台上，由于 DataGrid 控件已经升级为 GridView ，所以此控件已不能使用，按照文章下面的讨论，作者声称会尽快升级控件，但似乎在实现时碰到一些麻烦（如何确实表头各列的宽度），目前还没有结果。

目前我的做法：

1. 参照文章1中提到的作法，利用 CSS 来实现锁定表头的功能
2. 利用 Panel 控件，设置 ScrollBar 为 Vertical，再在其中放入 GridView 控件 ，可以实现竖向滚动条的功能
3. 利用 Atlas ，将上述 Panel 再放入 UpdatePanel ，以透明实现保持滚动条位置的功能

示例代码：

<h1>滚动条表格演示h1>
<style type="text/css">......
th {...}{...}{...}{
border-right: 1px solid silver;
position:relative;
top: expression(this.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.scrollTop-2); /**//**//**//*IE5+ only*/
}
style>

<atlas:ScriptManager ID="ScriptManager1" runat="server" EnablePartialRendering="True">
atlas:ScriptManager>
<br />
<asp:Panel ID="GridPanel" runat="server" Height="250px" ScrollBars="Auto" Width="562px">
   <atlas:UpdatePanel ID="UpdatePanel1" runat="server">
       <ContentTemplate>
         <asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="False" DataSourceID="ObjectDataSource1" SkinID="GridView" Width="434px">
          </asp:GridView>
       </ContentTemplate>
   </atlas:UpdatePanel>
</asp:Panel>

这样能基本上实现一个能够锁定表头、竖向滚动、能够在页面PostBack时保持滚动位置的表格，能够满足大部分应用需要。

ASP.NET 成功的其中一个原因在于它降低了 Web 开发人员的门槛。即便您不是计算机科学博士也可以编写 ASP.NET 代码。我在工作中遇到的许多 ASP.NET 开发人员都是自学成材的，他们在编写 C# 或 Visual Basic® 之前都在编写 Microsoft® Excel® 电子表格。现在，他们在编写 Web 应用程序，总的来说，他们所做的工作值得表扬。

但是与能力随之而来的还有责任，即使是经验丰富的 ASP.NET 开发人员也难免会出错。在多年的 ASP.NET 项目咨询工作中，我发现某些错误特别容易导致缺陷不断发生。其中某些错误会影响性能。其他错误会抑制可伸缩性。有些错误还会使开发团队耗费宝贵的时间来跟踪错误和意外的行为。

下面是会导致 ASP.NET 生产应用程序的发布过程中出现问题的 10 个缺陷以及可避免它们的方法。所有示例均来自我对真实的公司构建真实的 Web 应用程序的亲身体验，在某些情况下，我会通过介绍 ASP.NET 开发团队在开发过程中遇到的一些问题来提供相关的背景。

LoadControl 和输出缓存

极少有不使用用户控件的 ASP.NET 应用程序。在出现母版页之前，开发人员使用用户控件来提取公用内容，如页眉和页脚。即使在 ASP.NET 2.0 中，用户控件也提供了有效的方法来封装内容和行为以及将页面分为多个区域，这些区域的缓存能力可以独立于作为整体的页面进行控制（一种称为段缓存的特殊输出缓存形式）。

用户控件可以采用声明的方式加载，也可以强制加载。强制加载依赖于 Page.LoadControl，它实例化用户控件并返回控件引用。如果用户控件包含自定义类型的成员（例如，公共属性），则您可以转换该引用并从您的代码访问自定义成员。图 1中的用户控件实现名为 BackColor 的属性。以下代码加载用户控件并向 BackColor 分配一个值：

protected void Page_Load(object sender, EventArgs e)
{
// 加载用户控件并将其添加到页面中
Control control = LoadControl("~/MyUserControl.ascx");
PlaceHolder1.Controls.Add(control);
// 设置其背景色
((MyUserControl)control).BackColor = Color.Yellow;
}

以上代码实际上很简单，但却是一个等待粗心的开发人员掉进去的陷阱。您能找出其中的破绽吗？

如果您猜到该问题与输出缓存有关，那么您是正确的。正如您所看到的一样，上述代码示例编译和运行都正常，但是如果尝试将以下语句（完全合法）添加到 MyUserControl.ascx 中：

<%@ OutputCache Duration="5" VaryByParam="None" %>

则当您下一次运行该页面时，您将看到 InvalidCastException (oh joy!) 和以下错误消息：

“无法将类型为‘System.Web.UI.PartialCachingControl’的对象转换为类型‘MyUserControl’。”

因此，此代码在没有 OutputCache 指令时运行正常，但如果添加了 OutputCache 指令就会出错。ASP.NET 不应该以这种方式运行。页面（和控件）对于输出缓存应该是不可知的。那么，这代表什么意思？

问题在于为用户控件启用输出缓存时，LoadControl 不再返回对控件实例的引用；相反，它返回对 PartialCachingControl 实例的引用，而 PartialCachingControl 可能会也可能不会包装控件实例，具体取决于控件的输出是否被缓存。因此，如果开发人员调用 LoadControl 以动态加载用户控件并且为了访问控件特定的方法和属性而转换控件引用，他们必须注意进行该操作的方式，以便不管是否具有 OutputCache 指令，代码都可以运行。

图 2 说明动态加载用户控件以及转换返回的控件引用的正确方法。以下是其工作原理概要：

不管 .ascx 文件中是否具有 OutputCache 指令，图 2中的代码都将运行。虽然看起来复杂一点，但它会避免烦人的错误。简单并不总是代表易于维护。

会话和输出缓存

谈到输出缓存，ASP.NET 1.1 和 ASP.NET 2.0 都存在一个潜在的问题，该问题会影响在 Windows Server™ 2003 和 IIS 6.0 上运行的服务器中的输出缓存页。我曾经亲眼看到该问题在 ASP.NET 生产服务器中出现过两次，这两次都是通过关闭输出缓冲来解决的。后来我了解到有一个比禁用输出缓存更好的解决方案。以下是我第一次遇到该问题时的情况。

当时的情况是这样的，某个网站（我们在此称为 Contoso.com，它在小型 ASP.NET Web 领域中运行公共电子商务应用程序）与我的团队联系，抱怨他们遇到了“跨线程”错误。使用 Contoso.com 网站的客户常常突然丢失已经输入的数据，但却看到另一用户的相关数据。稍做分析即发现，跨线程这个描述并不准确；“跨会话”错误更为贴切。看起来 Contoso.com 是在会话状态中存储数据的，由于某些原因，用户会偶尔随机地连接到其他用户的会话。

我的一个团队成员编写了一个诊断工具，用来将每个 HTTP 请求和响应的关键要素（包括 Cookie 标头）记录到日志中。然后，他将该工具安装在 Contoso.com 的 Web 服务器上，并让其运行了几天。结果非常明显。大概每 100000 个请求中会发生一次这样的情况：ASP.NET 正确地为全新会话分配一个会话 ID 并返回 Set-Cookie 标头中的会话 ID。然后，它会在下一个紧相邻的请求中返回相同的会话 ID（即，相同的 Set-Cookie 标头），即使该请求已经与一个有效的会话相关联并且正确提交了 Cookie 中的会话 ID。实际上，ASP.NET 是随机将用户从他们自己的会话中切换出去并将他们连接到其他会话。

我们很惊讶，于是开始寻找原因。我们首先检查了 Contoso.com 的源代码，让我们感到欣慰的是，问题不在那。接着，为了确保问题与应用程序宿主在 Web 领域无关，我们只保留一个服务器在运行，而关闭了所有其他服务器。问题仍然存在，这并不意外，因为我们的日志显示匹配的 Set-Cookie 标头绝不会来自两个不同的服务器。ASP.NET 意外地生成了重复的会话 ID，这令人难以置信，因为它使用 .NET Framework RNGCryptoServiceProvider 类生成这些 ID，并且会话 ID 的长度足以确保相同的 ID 决不会生成两次（至少在下一个万亿年内不会生成两次）。除此之外，即使 RNGCryptoServiceProvider 错误地生成了重复的随机数字，也无法解释 ASP.NET 为何不可思议地将有效的会话 ID 替换为新的 ID（不唯一）。

凭直觉，我们决定看一下输出缓存。当 OutputCacheModule 缓存 HTTP 响应时，它必须小心不要缓存了 Set-Cookie 标头；否则，包含新会话 ID 的缓存响应会将缓存响应的所有接收者（以及其请求生成了缓存响应的用户）连接到同一会话。我们检查了源代码；Contoso.com 在两个页面中启用了输出缓存。我们关闭了输出缓存。结果，应用程序运行数天而没有发生一个跨会话问题。此后，它运行了两年多都没有发生任何错误。在具有不同应用程序和一组不同 Web 服务器的另一家公司中，我们看到完全相同的问题也消失了。就像在 Contoso.com 一样，消除输出缓存就能解决问题。

Microsoft 后来确认此行为源于 OutputCacheModule 中的问题。（当您阅读本文时，可能已经发布了更新。）当 ASP.NET 与 IIS 6.0 一起使用并且启用内核模式缓存时，OutputCacheModule 有时无法从它传递给 Http.sys 的缓存响应中删除 Set-Cookie 标头。下面是导致出现错误的特定事件顺序：

故事的寓意又是什么呢?会话状态和内核模式输出缓存不能混合使用。如果您在启用输出缓存的页中使用会话状态，并且应用程序在 IIS 6.0 上运行，则您需要关闭内核模式输出缓存。您仍将受益于输出缓存，但是因为内核模式输出缓存比普通输出缓存快得多，所以缓存不会同样有效。有关此问题的详细信息，请参见 support.microsoft.com/kb/917072。

您可以通过在页面的 OutputCache 指令中包含 VaryByParam="*" 属性来关闭单个页面的内核模式输出缓存，虽然这样做可能导致内存需求骤增。另一种更安全的方法是通过在 web.config 中包含下列元素来关闭整个应用程序的内核模式缓存：

<httpRuntime enableKernelOutputCache="false" />

您还可以使用注册表设置来全局性地禁用内核模式输出缓存，即禁用全部服务器的内核模式输出缓存。有关详细信息，请参见 support.microsoft.com/kb/820129。

每次我听到客户报告会话发生了费解的问题，我都会询问他们是否在任何页面中使用了输出缓存。如果确实使用了输出缓存，并且宿主操作系统是 Windows Server 2003，我会建议他们禁用内核模式输出缓存。问题通常就会迎刃而解。如果问题没有解决，则错误存在于代码中。警惕!

Forms 身份验证票证生存期

您能找出以下代码的问题吗？

FormsAuthentication.RedirectFromLoginPage(username, true);

此代码看似没有问题，但决不能在 ASP.NET 1.x 应用程序中使用，除非应用程序中其他位置的代码抵消了此语句的负面作用。如果您不能确定原因，请继续阅读。

FormsAuthentication.RedirectFromLoginPage 执行两个任务。首先，当 FormsAuthenticationModule 将用户重定向到登录页时，FormsAuthentication.RedirectFromLoginPage 将用户重定向到他们原来请求的页面。其次，它发布一个身份验证票证（通常携带在 Cookie 中，而且在 ASP.NET 1.x 中总是携带在 Cookie 中），这个票证允许用户在预定的一段时间内保持已经过身份验证状态。

问题就在于这个时间段。在 ASP.NET 1.x 中，向 RedirectFromLoginPage 传递另一个为 false 的参数会发出一个临时身份验证票证，该票证默认情况下在 30 分钟之后到期。（您可以使用 web.config 的 元素中的 Timeout 属性来更改超时期限。）然而，传递另一个为 true 的参数则会发出一个永久身份验证票证，其有效期为 50 年!这样就会发生问题，因为如果有人窃取了该身份验证票证，他们就可以在票证的有效期内使用受害者的身份访问网站。窃取身份验证票证有多种方法 — 在公共无线访问点探测未加密的通信、跨网站编写脚本、以物理方式访问受害者的计算机等等 — 因此，向 RedirectFromLoginPage 传递 true 比禁用您的网站的安全性好不了多少。幸运的是，此问题已经在 ASP.NET 2.0 中得到了解决。现在的 RedirectFromLoginPage 以相同的方式接受在 web.config 中为临时和永久身份验证票证指定的超时。

一种解决方案是决不在 ASP.NET 1.x 应用程序的 RedirectFromLoginPage 的第二个参数中传递 true。但是这不切实际，因为登录页的特点通常是包含一个“将我保持为登录状态”框，用户可以选中该框以收到永久而不是临时身份验证 Cookie。另一种解决方案是使用 Global.asax（如果您愿意的话，也可以使用 HTTP 模块）中的代码段，此代码段会在包含永久身份验证票证的 Cookie 返回浏览器之前对其进行修改。

图 3 包含一个这样的代码段。如果此代码段位于 Global.asax 中，它会修改传出永久 Forms 身份验证 Cookie 的 Expires 属性，以使 Cookie 在 24 小时后过期。通过修改注释为“新的过期日期”的行，您可以将超时设置为您喜欢的任何日期。

您可能会觉得奇怪，Application_EndRequest 方法调用本地 Helper 方法 (GetCookieFromResponse) 来检查身份验证 Cookie 的传出响应。Helper 方法是解决 ASP.NET 1.1 中另一个错误的方法，如果您使用 HttpCookieCollection 的字符串索引生成器来检查不存在的 Cookie，此错误会导致虚假 Cookie 添加到响应中。使用整数索引生成器作为 GetCookieFromResponse 可以解决该问题。

视图状态：无声的性能杀手

从某种意义上说，视图状态是有史以来最伟大的事情。毕竟，视图状态使得页面和控件能够在回发之间保持状态。因此，您不必像在传统的 ASP 中那样编写代码，以防止在单击按钮时文本框中的文本消失，或在回发后重新查询数据库和重新绑定 DataGrid。

但是视图状态也有缺点：当它增长得过大时，它便成为一个无声的性能杀手。某些控件（例如文本框）会根据视图状态作出相应判断。其他控件（特别是 DataGrid 和 GridView）则根据显示的信息量确定视图状态。如果 GridView 显示 200 或 300 行数据，我会望而生畏。即使 ASP.NET 2.0 视图状态大致是 ASP.NET 1 x 视图状态的一半大小，一个糟糕的 GridView 也可以容易地将浏览器和 Web 服务器之间的连接的有效带宽减少 50％ 或更多。

您可以通过将 EnableViewState 设置为 false 来关闭单个控件的视图状态，但某些控件（特别是 DataGrid）在不能使用视图状态时会失去某些功能。控制视图状态的更佳解决方案是将其保留在服务器上。在 ASP.NET 1.x 中，您可以重写页面的 LoadPageStateFromPersistenceMedium 和 SavePageStateToPersistenceMedium 方法并按您喜欢的方式处理视图状态。图 4 中的代码显示的重写可防止视图状态保留在隐藏字段中，而将其保留在会话状态中。当与默认会话状态进程模型一起使用时（即，会话状态存储在内存中的 ASP.NET 辅助进程中时），在会话状态中存储视图状态尤其有效。相反，如果会话状态存储在数据库中，则只有测试才能显示在会话状态中保留视图状态会提高还是降低性能。

在 ASP.NET 2.0 中使用相同的方法，但是 ASP.NET 2.0 能够提供更简单的方法将视图状态保留在会话状态中。首先，定义一个自定义页适配器，其 GetStatePersister 方法返回 .NET Framework SessionPageStatePersister 类的一个实例：

public class SessionPageStateAdapter :
System.Web.UI.Adapters.PageAdapter
{
public override PageStatePersister GetStatePersister ()
{
return new SessionPageStatePersister(this.Page);
}
}

然后，通过将 App.browsers 文件按以下方式放入应用程序的 App_Browsers 文件夹，将自定义页适配器注册为默认页适配器：

<browsers>
<browser refID="Default">
<controlAdapters>
<adapter controlType="System.Web.UI.Page"
adapterType="SessionPageStateAdapter" />
</controlAdapters>
</browser>
</browsers>

（您可以将文件命名为您喜欢的任何名称，只要它的扩展名为 .browsers 即可。）此后，ASP.NET 将加载页适配器并使用返回的 SessionPageStatePersister 以保留所有页面状态，包括视图状态。

使用自定义页适配器的一个缺点是它全局性地作用于应用程序中的每一页。如果您更愿意将其中一些页面的视图状态保留在会话状态中而不保留其他页面的视图状态，请使用图 4 中显示的方法。另外，如果用户在同一会话中创建多个浏览器窗口，您使用该方法可能会遇到问题。

SQL Server 会话状态：另一个性能杀手

ASP.NET 使得在数据库中存储会话状态变得简单：只需切换 web.config 中的开关，会话状态就会轻松地移动到后端数据库。对于在 Web 领域中运行的应用程序来说，这是一项重要功能，因为它允许该领域中的每个服务器共享会话状态的一个公共库。添加的数据库活动降低了单个请求的性能，但是可伸缩性的提高弥补了性能的损失。

这看起来都还不错，但是您略微考虑一下下列几点，情况就会有所不同：

换句话说，当您使用 SQL Server™ 会话状态选项时，您在每个请求中都要付出代价（两个数据库访问）— 甚至在与会话状态无关的页面的请求中。这会直接对整个网站的吞吐量造成负面影响。

图 5 消除不必要的会话状态数据库访问

那么您应该怎么办呢？很简单：禁用不使用会话状态的页中的会话状态。这样做总是一个好办法，但是当会话状态存储在数据库中时，该方法尤其重要。图 5 显示如何禁用会话状态。如果页面根本不使用会话状态，请在其 Page 指令中包含 EnableSessionState="false"，如下所示：

<%@ Page EnableSessionState="false" ... %>

该指令阻止会话状态管理器在每个请求中读取和写入会话状态数据库。如果页面从会话状态中读取数据，但却不写入数据（即，不修改用户会话的内容），则将 EnableSessionState 设置为 ReadOnly，如下所示：

<%@ Page EnableSessionState="ReadOnly" ... %>

最后，如果页面需要对会话状态进行读/写访问，则省略 EnableSessionState 属性或将其设置为 true：

<%@ Page EnableSessionState="true" ... %>

通过以这种方式控制会话状态，可以确保 ASP.NET 只在真正需要时才访问会话状态数据库。消除不必要的数据库访问是构建高性能应用程序的第一步。

顺便说一下，EnableSessionState 属性是公开的。该属性自 ASP.NET 1.0 以来就已经进行了说明,但是我至今仍很少见到开发人员利用该属性。也许是因为它对于内存中的默认会话状态模型并不十分重要。但是它对于 SQL Server 模型却很重要。

未缓存的角色

以下语句经常出现于 ASP.NET 2.0 应用程序的 web.config 文件以及介绍 ASP.NET 2.0 角色管理器的示例中：

<roleManager enabled="true" />

但正如以上所示，该语句确实会对性能产生明显的负面影响。您知道为什么吗？

默认情况下，ASP.NET 2.0 角色管理器不会缓存角色数据。相反，它会在每次需要确定用户属于哪个角色（如果有）时参考角色数据存储。这意味着一旦用户经过了身份验证，任何利用角色数据的页（例如，使用启用了安全裁减设置的网站图的页，以及使用 web.config 中基于角色的 URL 指令进行访问受到限制的页）将导致角色管理器查询角色数据存储。如果角色存储在数据库中，那么对于每个请求需要访问多个数据库的情况，您可以轻松地免除访问多个数据库。解决方案是配置角色管理器以在 Cookie 中缓存角色数据：

<roleManager enabled="true" cacheRolesInCookie="true" />

您可以使用其他<roleManager> 属性控制角色 Cookie 的特征 — 例如，Cookie 应保持有效的期限（以及角色管理器因此返回角色数据库的频率）。角色 Cookie 默认情况下是经过签名和加密的，因此安全风险虽然不为零，但也有所缓解。

配置文件属性序列化

ASP.NET 2.0 配置文件服务为保持每个用户的状态（例如个性化首选项和语言首选项）的问题提供了一个现成的解决方案。要使用配置文件服务，您可以定义一个 XML 配置文件，其中包含要保留的代表单个用户的属性。然后，ASP.NET 编译一个包含相同属性的类，并通过添加到页的配置文件属性提供对类实例的强类型访问。

配置文件灵活性很强，它甚至允许将自定义数据类型用作配置文件属性。但是，其中却存在一个问题，我亲眼看到该问题导致开发人员出差错。图 6 包含一个名为 Posts 的简单类，以及将 Posts 用作配置文件属性的配置文件定义。但是，该类和该配置文件在运行时会产生意外的行为。您能找出其中的原因吗？

问题在于 Posts 包含一个名为 _count 的私有字段，该字段必须进行序列化和反序列化，才能完全冻结和重新冻结类实例。但是 _count 却没有经过序列化和反序列化，因为它是私有的，而且默认情况下 ASP.NET 配置文件管理器使用 XML 序列化对自定义类型进行序列化和反序列化。XML 序列化程序将忽略非公共成员。因此，会对 Posts 的实例进行序列化和反序列化，但是每次反序列化类实例时，_count 都会重设为 0。

一种解决方案是使 _count 成为公共字段而非私有字段。另一种解决方案是使用公共读/写属性封装 _count。最佳解决方案是将 Posts 标记为可序列化（使用 SerializableAttribute），并将配置文件管理器配置为使用 .NET Framework 二进制序列化程序对类实例进行序列化和反序列化。该解决方案能够保持类本身的设计。与 XML 序列化程序不同的是，二进制序列化程序序列化字段，而不管是否可以访问。图 7 显示 Posts 类的修复版本并突出显示了更改的附带配置文件定义。

您应该牢记的一点是，如果您使用自定义数据类型作为配置文件属性，并且该数据类型具有必须序列化才能完全序列化类型实例的非公共数据成员，则在属性声明中使用 serializeAs="Binary" 属性并确保类型本身是可序列化的。否则，将无法进行完整的序列化，并且您还将浪费时间来尝试确定配置文件无法工作的原因。

线程池饱和

在执行数据库查询并等待 15 秒或更长时间来获得返回的查询结果时，我经常对看到的实际的 ASP.NET 页数感到非常惊讶。（我也等待了 15 分钟才看到查询结果！）有时，延迟是由于返回的数据量很大而导致的不可避免的无奈结果；而有时，延迟则是由于数据库的设计不佳导致的。但不管是什么原因，长时间的数据库查询或任何类型的长时间 I/O 操作在 ASP.NET 应用程序中都会导致吞吐量的下降。

关于这个问题我以前已经详细地描述过，所以在此就不再作过多的说明了。我只说一点就够了，ASP.NET 依赖于有限的线程池处理请求，如果所有线程都被占用来等待数据库查询、Web 服务调用或其他 I/O 操作完成，则在某个操作完成并且释放出一个线程之前，其他请求都必须排队等待。当请求排队时，性能会急剧下降。如果队列已满，则 ASP.NET 会使随后的请求失败并出现 HTTP 503 错误。这种情况不是我们希望在 Web 生产服务器的生产应用程序上所乐见的。

解决方案非异步页面莫属，这是 ASP.NET 2.0 中最佳却鲜为人知的功能之一。对异步页面的请求从一个线程上开始，但是当它开始一个 I/O 操作时，它将返回该线程以及 ASP.NET 的 IAsyncResult 接口。操作完成后，请求通过 IAsyncResult 通知 ASP.NET，ASP.NET 从池中提取另一个线程并完成对请求的处理。值得注意的是，当 I/O 操作发生时，没有占用线程池线程。这样可以通过阻止其他页面（不执行较长的 I/O 操作的页面）的请求在队列中等待，从而显著地提高吞吐量。

您可以在 MSDN®Magazine 的 2005 年 10 月刊中阅读有关异步页面的所有信息。I/O 绑定而不是计算机绑定且需要很长时间执行的任何页面很有可能成为异步页面。

当我将关于异步页面的信息告知开发人员时，他们经常回答“那真是太棒了，但是我的应用程序中并不需要它们。”对此我回答说：“你们的任何页面需要查询数据库吗？它们调用 Web 服务吗？您是否已经检查 ASP.NET 性能计数器中关于排队请求和平均等待时间的统计信息？即使您的应用程序至今运行正常，但是随着您的客户规模的增长，应用程序的负载可能会增加。”

实际上，绝大多数实际的 ASP.NET 应用程序都需要异步页面。请切记这一点！

模拟和 ACL 授权

以下是一个简单的配置指令，但是每当在 web.config 中看到它时都让我眼前一亮：

<identity impersonate="true" />

此指令在 ASP.NET 应用程序中启用客户端模拟。它将代表客户端的访问令牌附加到处理请求的线程，以便操作系统执行的安全性检查针对的是客户端身份而不是辅助进程身份。ASP.NET 应用程序很少需要模拟；我的经验告诉我，开发人员通常都是由于错误的原因而启用模拟的。以下是原因所在。

开发人员经常在 ASP.NET 应用程序中启用模拟，以便可以使用文件系统权限来限制对页面的访问。如果 Bob 没有查看 Salaries.aspx 的权限，则开发人员将会启用模拟，以便可以通过将访问控制列表 (ACL) 设置为拒绝 Bob 的读取权限，阻止 Bob 查看 Salaries.aspx。但是存在以下隐患：对于 ACL 授权来说，模拟是不必要的。在 ASP.NET 应用程序中启用 Windows 身份验证时，ASP.NET 会自动为请求的每个 .aspx 页面检查 ACL 并拒绝没有读取文件权限的调用者的请求。即使禁用了模拟，它仍会这样操作。

有的时候需要证明模拟的合理性。但是您通常可以用良好的设计来避免它。例如，假定 Salaries.aspx 在数据库中查询只有管理人员才能知道的工资信息。通过模拟，您可以使用数据库权限拒绝非管理人员查询工资数据的能力。或者您可以不考虑模拟，并且通过为 Salaries.aspx 设置 ACL 以使非管理人员不具有读取权限，从而限制对工资数据的访问。后一种方法提供的性能更佳，因为它完全避免了模拟。它也消除了不必要的数据库访问。为什么查询数据库仅由于安全原因被拒绝？

顺便说一下，我曾经帮助对一个传统的 ASP 应用程序进行故障排除，该应用程序由于内存占用不受限制而定期重新启动。一个没有经验的开发人员将目标 SELECT 语句转换成了 SELECT *，而没有考虑要查询的表包含图像，这些图像很大而且数目很多。问题由于未检测到内存泄漏而恶化。（我的托管代码领域！）多年来运行正常的应用程序开始突然停止工作，因为以前返回一两千字节数据的 SELECT 语句现在却返回了几兆字节。如果再加上不充分的版本控制，开发团队的生活将不得不“亢奋起来”— 这里所谓的“亢奋”，就如同当您在晚上要睡觉时，还不得不看着您的孩子玩令人厌烦的足球游戏一样。

理论上，传统的内存泄漏不会发生在完全由托管代码组成的 ASP.NET 应用程序中。但是内存使用量不足会通过强制垃圾收集更频繁地发生而影响性能。即使是在 ASP.NET 应用程序中，也要警惕 SELECT *!

不要完全信赖它 — 请设置数据库的配置文件！

作为一名顾问，我经常被询问为何应用程序没有按预期执行。最近，有人询问我的团队为何 ASP.NET 应用程序只完成请求文档所需吞吐量（每秒的请求数）的大约 1/100。我们以前所发现的问题是我们在不能正常运行的 Web 应用程序中发现的问题特有的 — 和我们所有人应该认真对待的教训。

我们运行 SQL Server Profiler 并监视此应用程序和后端的数据库之间的交互情况。在一个更极端的案例中，仅仅只是一个按钮单击，就导致数据库发生了 1,500 多个错误。您不能那样构建高性能的应用程序。良好的体系结构总是从良好的数据库设计开始。不管您的代码的效率有多高，如果它被编写不佳的数据库所拖累，就会不起作用。

糟糕的数据访问体系结构通常源于下面的一个或多个方面：

必须先确定问题才能对其进行处理。确定数据访问问题的方式是运行 SQL Server Profiler 或等效的工具以查看后台正在执行的操作。检查应用程序和数据库之间的通信之后，性能调整才完成。尝试一下 — 您可能会对您的发现大吃一惊。