ASP.NET 编程心得

1. 在页面中，如果一组控件的状态是互相关联的。比如，如果隐藏就同时隐藏等。那么就把它们放在同一个Panel中，这样隐藏的时候直接对Panel操作就可以了。

2. 在编写程序的时候，一点要进行数据合法性先判断，避免一切可以避免的异常。特别是对Session,Application这些值为null的时候的判断。

3. 在ASP.NET页面中，有些页面由于被多种情况调用(比如，一个页面可以为多个角色使用，但是不同得角色可能显示的内容有所不同)，那么就很可能出现Page_Load中有大段的判断代码。这样对测试和维护都造成了困难。可以考虑建立为每种用户建立一个特定的界面。然后通过将相同的控件全部用UserControl来替代，这样就实现了页面局部的重用和减轻了后台代码的复杂度。

4. 如果一个已有的类不能满足要求，那么有两种方式。一种是继承这个类，并重写/添加一些新的方法；一种是新建一个类，这个类组合了几个已有的类，通过这几个类的协作来满足要求。后者优先考虑。

5. 在使用“门面模式”的时候，应该根据一定的分类分别为每个分类建立一个“门面”，而不应该整个子系统或者模块只有一个统一的门面。这样一个统一的门面里面会很乱，方法会很多。而且当开发周期长的话，有一些方法可能你已经写了，但是由于实在记不住，所以可能重复的开发了具有同样功能的函数。比如Duwamish的结构中，其中BusinessFacade类库中就分别为客户，订单和产品三个实体建立各自的“门面”

6. 在显示表格的时候，有时候用户要求数据一定要实时的更新。比较普遍的做法就是在更新了数据以后，再到数据库把最新的数据取出来，重新的绑定到控件中(如：DataGrid)。但是如果数据量很大的话，这样的话会造成网络的传输负担。所以你可以通过更新函数传回一个标志符。这个标志符用来表示更新的操作是否成功。如果成功。我这里用DataGrid来举例，你就可以在ItemCommand命令中直接对显示的信息进行修改。这样就可以在不抓取新数据的情况下来实时的更新状态。

7. 系统上线以后，用户会对发现的问题和需要改进的地方进行反馈。而用户使用的语言与程序员使用的语言肯定是有差别的。特别是对系统出现问题的描述上，用户无法准确的描述出现问题的环境和具体的现象。这个时候系统就需要一个异常处理模块。通过这个模块，将系统出现的异常时的环境和错误信息保存起来。这样可以有效大的帮助程序员来排除系统的缺陷。

8. 对于系统“容易改变的部分”和“使用广泛”的部分一定要集中管理。这样将便于维护工作。

9. 危险操作,如：删除操作。一定需要有提示，让人再审查一下自己操作是否正确。

10. 充分利用控件的ToolTip属性(在HtmlControl中对应的是Title属性)，这样当用户的鼠标指针悬停在控件上的时候就可以出现简单的提示。这是很方便的，可以增加系统的友好程度。

11. 在进行数据验证的时候，首选是Microsoft提供的验证控件。

12. 如果不希望用户使用多线程的下载工具，可以使用按钮(Button)而不是超链接的方式进行下载。

13. 默认的情况下在下拉菜单中选择一个值后，下拉菜单依然占据着焦点。而现在的鼠标大都是带滚轮的3D鼠标。在从下拉菜单选择了值以后，如果用滚轮来翻页有可能回改变下拉菜单中的值，从而导致了误操作的可能性。这里目前的解决方案是利用下拉菜单的onchange属性。在从下拉菜单选择了不同的值以后，自动将焦点转移到另外的控件或者一个行藏控件上。这样可以从一定程度上减少用户失误操作的次数。具体的代码如下：

< script lanuage = javascript >
          function  setFocus()
          ... {
                 document.all.HIDDENCONTROL.focus();           //这里HIDDENCONTROL是指在下拉菜单失去焦点以后得到焦点的  控件
         }
</ script >

< select onchange  =   " setFocus " >
        < option > ... </ option >
        < option >  ...  </ option >
</ select >

14. CheckList 是一个简单而有效的检查方式。头脑风暴是必要的，但是一张优秀的CheckList不仅可以减少头脑风暴的重复劳动，而且可以减少错误的发生。

15. 系统在进行需求开发的时候一定需要明确的问题：

 

      A) 系统边界；(可以通过对系统需要实现的功能点来描述系统应该完成什么样的内容。但是如果能在需求说明书中通过一段文字明确对系统的边界进行说明是一种好的方法);

      B) 系统的功能。(系统需要实现哪些功能点，每个功能点的操作者是谁一定需要明确，具体的操作对象);

      C) 系统边界检查。(既然系统有边界，系统需要正常运行需要有初始数据，这些数据如何从边界外进入系统。系统需要产生数据，如何将这些产生的数据结果提供给边界外的系统都需要明确，无论是webservice, 导出文档的方式。)

      D) 界面原型。(2008-7-28)

16. 我们写需求，做设计(包括：概要设计、详细设计)都是一个自上而下的过程。其实写代码也是，也是自上而下的过程，以ASP.NET为例，先页面，然后分解到业务逻辑和数据操作，并且逐层实现。这样可以验证代码的完整性(可以覆盖所有需要完成的功能)，并且不会应为凭空想象而产生一些根本就不会引用的方法。至于产品和项目的关系，我觉得是相互关系，产品来源于项目，并且对项目产生影响。昨天和一个学Java的朋友聊天，他说在他们的源码管理器(CVS)中存在主线和支线的概念，主线就是一个产品，而支线就是一个个具体的项目，那么具体项目中的功能模块经过分析以后可以被反射到主线(产品)中，然后再后续的项目中就可以使用主线对应的功能了。我觉得这个描述是一个很形象和具体的说法了。(2008-10-27)

17. 一个核心系统能做什么不能做什么需要限定清楚，这样才能知道那些是需要借助核心完成的那些是需要重新根据项目写的，否则会在写函数的时候由于不知其归属而畏首畏脚。(2008-10-28)

 

18. 如果是涉及相对昂贵的操作，如：文件处理、数据库访问等。那么在对应的方法中需要先尽量的对传入的参数进行有效性的验证，如果发现输入参数存在非法值那么需要通过异常的方式抛出。如果不是这样的操作，如：纯粹的逻辑处理，并且不需要对异常进行处理，那么在编码时就可以仅仅关注于逻辑，因为如果参数存在非法值那么系统也会以你预想的方式来抛出异常。(2008-11-6)

 

19. 在进行系统分析的时候，最主要的关系是分离对象(对象的职责)以及对象之间的关系。特别是在多人合作的基础上，更需要先确定对象模型(比如：存在哪些对象，这些对象有哪些属性和实现哪些方法)，然后确定对象的关系。这样可以避免一些多人开发中可能仅仅看到自己当前业务对应对象一方面的信息的片面性。(2008-11-7)