1.书写格式
示例代码：

存储过程SQL文书写格式例
select
        c.dealerCode,
        round(sum(c.submitSubletAmountDLR + c.submitPartsAmountDLR + c.submitLaborAmountDLR) / count(*), 2) as avg,
        decode(null, 'x', 'xx', 'CNY')
from (
        select
                a.dealerCode,
                a.submitSubletAmountDLR,
                a.submitPartsAmountDLR,
                a.submitLaborAmountDLR
        from SRV_TWC_F a
        where (to_char(a.ORIGSUBMITTIME, 'yyyy/mm/dd') >= 'Date Range(start)'
        and to_char(a.ORIGSUBMITTIME, 'yyyy/mm/dd') <= 'Date Range(end)'  
        and nvl(a.deleteflag, '0') <> '1')
        union all
        select
                b.dealerCode,
                b.submitSubletAmountDLR,
                b.submitPartsAmountDLR,
                b.submitLaborAmountDLR
        from SRV_TWCHistory_F b
        where (to_char(b.ORIGSUBMITTIME, 'yyyy/mm/dd') >= 'Date Range(start)'
        and to_char(b.ORIGSUBMITTIME,'yyyy/mm/dd') <= 'Date Range(end)'  
        and nvl(b.deleteflag,'0') <> '1')
) c
group by c.dealerCode
order by avg desc;

Java source里的SQL字符串书写格式例
strSQL = "insert into Snd_FinanceHistory_Tb "
    + "(DEALERCODE, "
    + "REQUESTSEQUECE, "
    + "HANDLETIME, "
    + "JOBFLAG, "
    + "FRAMENO, "
    + "INMONEY, "
    + "REMAINMONEY, "
    + "DELETEFLAG, "
    + "UPDATECOUNT, "
    + "CREUSER, "
    + "CREDATE, "
    + "HONORCHECKNO, "
    + "SEQ) "
    + "values ('" + draftInputDetail.dealerCode + "', "
    + "'" + draftInputDetail.requestsequece + "', "
    + "sysdate, "
    + "'07', "
    + "'" + frameNO + "', "
    + requestMoney + ", "
    + remainMoney + ", "
    + "'0', "
    + "0, "
    + "'" + draftStruct.employeeCode + "', "
    + "sysdate, "
    + "'" + draftInputDetail.honorCheckNo + "', "
    + index + ")";

  1).缩进
    对于存储过程文件，缩进为8个空格
    对于Java source里的SQL字符串，不可有缩进，即每一行字符串不可以空格开头

  2).换行
    1>.Select/From/Where/Order by/Group by等子句必须另其一行写
    2>.Select子句内容如果只有一项，与Select同行写
    3>.Select子句内容如果多于一项，每一项单独占一行，在对应Select的基础上向右缩进8个空格（Java source无缩进）
    4>.From子句内容如果只有一项，与From同行写
    5>.From子句内容如果多于一项，每一项单独占一行，在对应From的基础上向右缩进8个空格（Java source无缩进）
    6>.Where子句的条件如果有多项，每一个条件占一行，以AND开头，且无缩进
    7>.(Update)Set子句内容每一项单独占一行，无缩进
    8>.Insert子句内容每个表字段单独占一行，无缩进；values每一项单独占一行，无缩进
    9>.SQL文中间不允许出现空行
    10>.Java source里单引号必须跟所属的SQL子句处在同一行，连接符（"+"）必须在行首

  3).空格
    1>.SQL内算数运算符、逻辑运算符连接的两个元素之间必须用空格分隔
    2>.逗号之后必须接一个空格
    3>.关键字、保留字和左括号之间必须有一个空格

2.不等于统一使用"<>"
  Oracle认为"!="和"<>"是等价的，都代表不等于的意义。为了统一，不等于一律使用"<>"表示

3.使用表的别名
  数据库查询，必须使用表的别名

4.SQL文对表字段扩展的兼容性
  在Java source里使用Select *时，严禁通过getString(1)的形式得到查询结果，必须使用getString("字段名")的形式
  使用Insert时，必须指定插入的字段名，严禁不指定字段名直接插入values

5.减少子查询的使用
  子查询除了可读性差之外，还在一定程度上影响了SQL运行效率
  请尽量减少使用子查询的使用，用其他效率更高、可读性更好的方式替代

6.适当添加索引以提高查询效率
  适当添加索引可以大幅度的提高检索速度
  请参看ORACLE SQL性能优化系列

7.对数据库表操作的特殊要求
  本项目对数据库表的操作还有以下特殊要求：

  1).以逻辑删除替代物理删除
    注意：现在数据库表中数据没有物理删除，只有逻辑删除
    以deleteflag字段作为删除标志，deleteflag='1'代表此记录被逻辑删除，因此在查询数据时必须考虑deleteflag的因素
    deleteflag的标准查询条件：NVL(deleteflag, '0') <> '1'

  2).增加记录状态字段
    数据库中的每张表基本都有以下字段：DELETEFLAG、UPDATECOUNT、CREDATE、CREUSER、UPDATETIME、UPDATEUSER
    要注意在对标进行操作时必须考虑以下字段

    插入一条记录时要置DELETEFLAG='0', UPDATECOUNT=0, CREDATE=sysdate, CREUSER=登录User
    查询一条记录时要考虑DELETEFLAG，如果有可能对此记录作更新时还要取得UPDATECOUNT作同步检查
    修改一条记录时要置UPDATETIME=sysdate, UPDATEUSER=登录User, UPDATECOUNT=(UPDATECOUNT+1) mod 1000,
    删除一条记录时要置DELETEFLAG='1'

  3).历史表
    数据库里部分表还存在相应的历史表，比如srv_twc_f和srv_twchistory_f
    在查询数据时除了检索所在表之外，还必须检索相应的历史表，对二者的结果做Union（或Union All）

8.用执行计划分析SQL性能
  EXPLAIN PLAN是一个很好的分析SQL语句的工具，它可以在不执行SQL的情况下分析语句
  通过分析，我们就可以知道ORACLE是怎样连接表，使用什么方式扫描表（索引扫描或全表扫描），以及使用到的索引名称

  按照从里到外，从上到下的次序解读分析的结果
  EXPLAIN PLAN的分析结果是用缩进的格式排列的，最内部的操作将最先被解读，如果两个操作处于同一层中，带有最小操作号的将首先被执行

  目前许多第三方的工具如PLSQL Developer和TOAD等都提供了极其方便的EXPLAIN PLAN工具
  PG需要将自己添加的查询SQL文记入log，然后在EXPLAIN PLAN中进行分析，尽量减少全表扫描

ORACLE SQL性能优化系列

1.选择最有效率的表名顺序(只在基于规则的优化器中有效)
   ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，因此FROM子句中写在最后的表（基础表driving table）将被最先处理
   在FROM子句中包含多个表的情况下，必须选择记录条数最少的表作为基础表
   当ORACLE处理多个表时，会运用排序及合并的方式连接它们
   首先，扫描第一个表（FROM子句中最后的那个表)并对记录进行排序；
   然后扫描第二个表（FROM子句中最后第二个表)；
   最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并
   例如:
     表 TAB1 16,384 条记录
     表 TAB2 5 条记录
     选择TAB2作为基础表 (最好的方法)
     select count(*) from tab1,tab2 执行时间0.96秒
     选择TAB2作为基础表 (不佳的方法)
     select count(*) from tab2,tab1 执行时间26.09秒

   如果有3个以上的表连接查询，那就需要选择交叉表（intersection table）作为基础表，交叉表是指那个被其他表所引用的表
   例如:
     EMP表描述了LOCATION表和CATEGORY表的交集
       SELECT *
       FROM LOCATION L,
       CATEGORY C,
       EMP E
       WHERE E.EMP_NO BETWEEN 1000 AND 2000
       AND E.CAT_NO = C.CAT_NO
       AND E.LOCN = L.LOCN

     将比下列SQL更有效率
       SELECT *
       FROM EMP E ,
       LOCATION L ,
       CATEGORY C
       WHERE E.CAT_NO = C.CAT_NO
       AND E.LOCN = L.LOCN
       AND E.EMP_NO BETWEEN 1000 AND 2000

2.WHERE子句中的连接顺序
  ORACLE采用自下而上的顺序解析WHERE子句
  根据这个原理，表之间的连接必须写在其他WHERE条件之前，那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾
  例如：
     (低效,执行时间156.3秒)
       SELECT *
       FROM EMP E
       WHERE SAL > 50000
       AND JOB = 'MANAGER'
       AND 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=E.EMPNO);

     (高效,执行时间10.6秒)
       SELECT *
       FROM EMP E
       WHERE 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=E.EMPNO)
       AND SAL > 50000
       AND JOB = 'MANAGER';

3.SELECT子句中避免使用'*'
  当你想在SELECT子句中列出所有的COLUMN时，使用动态SQL列引用'*'是一个方便的方法，不幸的是，这是一个非常低效的方法
  实际上，ORACLE在解析的过程中，会将'*'依次转换成所有的列名
  这个工作是通过查询数据字典完成的，这意味着将耗费更多的时间

4.减少访问数据库的次数
  当执行每条SQL语句时，ORACLE在内部执行了许多工作：解析SQL语句，估算索引的利用率，绑定变量，读数据块等等
  由此可见，减少访问数据库的次数，就能实际上减少ORACLE的工作量
  例如：
    以下有三种方法可以检索出雇员号等于0342或0291的职员
    方法1 (最低效)
      SELECT EMP_NAME, SALARY, GRADE
      FROM EMP
      WHERE EMP_NO = 342;

      SELECT EMP_NAME, SALARY, GRADE
      FROM EMP
      WHERE EMP_NO = 291;

    方法2 (次低效)
      DECLARE
      CURSOR C1 (E_NO NUMBER) IS
      SELECT EMP_NAME,SALARY,GRADE
      FROM EMP
      WHERE EMP_NO = E_NO;
      BEGIN
      OPEN C1(342);
      FETCH C1 INTO …,…,…;
      …
      OPEN C1(291);
      FETCH C1 INTO …,…,…;
      …
      CLOSE C1;
      END;                                  

    方法2 (高效)
      SELECT A.EMP_NAME, A.SALARY, A.GRADE,
             B.EMP_NAME, B.SALARY, B.GRADE
      FROM EMP A, EMP B
      WHERE A.EMP_NO = 342
      AND B.EMP_NO = 291;

5.使用DECODE函数来减少处理时间
  使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表
  例如：
    SELECT COUNT(*), SUM(SAL)
    FROM EMP
    WHERE DEPT_NO = '0020'
    AND ENAME LIKE 'SMITH%';

    SELECT COUNT(*), SUM(SAL)
    FROM EMP
    WHERE DEPT_NO = '0030'
    AND ENAME LIKE 'SMITH%';

    你可以用DECODE函数高效地得到相同结果
    SELECT COUNT(DECODE(DEPT_NO, '0020', 'X', NULL)) D0020_COUNT,
    COUNT(DECODE(DEPT_NO, '0030', 'X', NULL)) D0030_COUNT,
    SUM(DECODE(DEPT_NO, '0020', SAL, NULL)) D0020_SAL,
    SUM(DECODE(DEPT_NO, 0030, SAL, NULL)) D0030_SAL
    FROM EMP
    WHERE ENAME LIKE 'SMITH%';

  'X'表示任何一个字段
  类似的，DECODE函数也可以运用于GROUP BY和ORDER BY子句中

6.用Where子句替换HAVING子句
  避免使用HAVING子句，HAVING只会在检索出所有记录之后才对结果集进行过滤，这个处理需要排序、统计等操作
  如果能通过WHERE子句限制记录的数目，那就能减少这方面的开销
  例如：
    低效
    SELECT REGION, AVG(LOG_SIZE)
    FROM LOCATION
    GROUP BY REGION
    HAVING REGION REGION != 'SYDNEY'
    AND REGION != 'PERTH'

    高效
    SELECT REGION, AVG(LOG_SIZE)
    FROM LOCATION
    WHERE REGION REGION != 'SYDNEY'
    AND REGION != 'PERTH'
    GROUP BY REGION

7.减少对表的查询
  在含有子查询的SQL语句中，要特别注意减少对表的查询
  例如：
    低效
    SELECT TAB_NAME
    FROM TABLES
    WHERE TAB_NAME = (SELECT TAB_NAME
                      FROM TAB_COLUMNS
                      WHERE VERSION = 604)
    AND DB_VER = (SELECT DB_VER
                  FROM TAB_COLUMNS
                  WHERE VERSION = 604)

    高效
    SELECT TAB_NAME
    FROM TABLES
    WHERE (TAB_NAME, DB_VER) = (SELECT TAB_NAME, DB_VER
                                FROM TAB_COLUMNS
                                WHERE VERSION = 604)

  Update多个Column例子：
    低效
    UPDATE EMP
    SET EMP_CAT = (SELECT MAX(CATEGORY)
                   FROM EMP_CATEGORIES),
    SAL_RANGE = (SELECT MAX(SAL_RANGE)
                 FROM EMP_CATEGORIES)
    WHERE EMP_DEPT = 0020;

    高效
    UPDATE EMP
    SET (EMP_CAT, SAL_RANGE) = (SELECT MAX(CATEGORY), MAX(SAL_RANGE)
                                FROM EMP_CATEGORIES)
    WHERE EMP_DEPT = 0020;

8.使用表的别名(Alias)
  当在SQL语句中连接多个表时，请使用表的别名并把别名前缀于每个Column上
  这样可以减少解析的时间并减少那些由Column歧义引起的语法错误

9.用EXISTS替代IN                                   
  在许多基于基础表的查询中，为了满足一个条件，往往需要对另一个表进行联接
  在这种情况下，使用EXISTS(或NOT EXISTS)通常将提高查询的效率
    低效
    SELECT *
    FROM EMP (基础表)
    WHERE EMPNO > 0
    AND DEPTNO IN (SELECT DEPTNO
                   FROM DEPT
                   WHERE LOC = 'MELB')

    高效
    SELECT *
    FROM EMP (基础表)
    WHERE EMPNO > 0
    AND EXISTS (SELECT 'X'
    FROM DEPT
    WHERE DEPT.DEPTNO = EMP.DEPTNO
    AND LOC = 'MELB')

10.用NOT EXISTS替代NOT IN
  在子查询中，NOT IN子句将执行一个内部的排序和合并
  无论在哪种情况下，NOT IN都是最低效的，因为它对子查询中的表执行了一个全表遍历
  为了避免使用NOT IN，我们可以把它改写成外连接(Outer Joins)或NOT EXISTS
  例如：
    SELECT …
    FROM EMP
    WHERE DEPT_NO NOT IN (SELECT DEPT_NO
                          FROM DEPT
                          WHERE DEPT_CAT = 'A');

    为了提高效率改写为
    高效
    SELECT …
    FROM EMP A, DEPT B
    WHERE A.DEPT_NO = B.DEPT(+)
    AND B.DEPT_NO IS NULL
    AND B.DEPT_CAT(+) = 'A'

    最高效
    SELECT …
    FROM EMP E
    WHERE NOT EXISTS (SELECT 'X'
                      FROM DEPT D
                      WHERE D.DEPT_NO = E.DEPT_NO
                      AND DEPT_CAT = 'A');

11.用表连接替换EXISTS
  通常来说，采用表连接的方式比EXISTS更有效率
  例如：
    SELECT ENAME
    FROM EMP E
    WHERE EXISTS (SELECT 'X'
                  FROM DEPT
                  WHERE DEPT_NO = E.DEPT_NO
                  AND DEPT_CAT = 'A');

    更高效
    SELECT ENAME
    FROM DEPT D, EMP E
    WHERE E.DEPT_NO = D.DEPT_NO
    AND DEPT_CAT = 'A';

12.用EXISTS替换DISTINCT
  当提交一个包含多表信息（比如部门表和雇员表）的查询时，避免在SELECT子句中使用DISTINCT，一般可以考虑用EXIST替换
  例如：
    低效
    SELECT DISTINCT DEPT_NO, DEPT_NAME
    FROM DEPT D, EMP E
    WHERE D.DEPT_NO = E.DEPT_NO

    高效
    SELECT DEPT_NO, DEPT_NAME
    FROM DEPT D
    WHERE EXISTS (SELECT 'X'
                  FROM EMP E
                  WHERE E.DEPT_NO = D.DEPT_NO);

  EXISTS使查询更为迅速，因为RDBMS核心模块将在子查询的条件一旦满足后，立刻返回结果

13.用索引提高效率
  索引是表的一个概念部分，用来提高检索数据的效率。实际上，ORACLE使用了一个复杂的自平衡B-tree结构
  通常，通过索引查询数据比全表扫描要快。当ORACLE找出执行查询和Update语句的最佳路径时，ORACLE优化器将使用索引
  同样，在联结多个表时使用索引也可以提高效率。另一个使用索引的好处是，它提供了主键（primary key）的唯一性验证

  除了那些LONG或LONG RAW数据类型，你可以索引几乎所有的列
  通常在大型表中使用索引特别有效，当然，在扫描小表时，使用索引同样能提高效率

  虽然使用索引能得到查询效率的提高，但是我们也必须注意到它的代价
  索引需要空间来存储，也需要定期维护，每当有记录在表中增减或索引列被修改时，索引本身也会被修改
  这意味着每条记录的INSERT、DELETE、UPDATE将为此多付出4、5次的磁盘I/O
  因为索引需要额外的存储空间和处理，那些不必要的索引反而会使查询反应时间变慢

  ORACLE对索引有两种访问模式：
  1).索引唯一扫描（INDEX UNIQUE SCAN）
    大多数情况下, 优化器通过WHERE子句访问INDEX
    例如：
      表LODGING有两个索引：建立在LODGING列上的唯一性索引LODGING_PK和建立在MANAGER列上的非唯一性索引LODGING$MANAGER
      SELECT *
      FROM LODGING
      WHERE LODGING = 'ROSE HILL';

      在内部，上述SQL将被分成两步执行：
      首先，LODGING_PK索引将通过索引唯一扫描的方式被访问，获得相对应的ROWID；然后通过ROWID访问表的方式执行下一步检索
      如果被检索返回的列包括在INDEX列中，ORACLE将不执行第二步的处理（通过ROWID访问表）
      因为检索数据保存在索引中，单单访问索引就可以完全满足查询结果

  2).索引范围查询(INDEX RANGE SCAN)
    适用于两种情况:
    1>.基于唯一性索引的一个范围的检索
    2>.基于非唯一性索引的检索
    例1
      SELECT LODGING
      FROM LODGING
      WHERE LODGING LIKE 'M%';

      WHERE子句条件包括一系列值，ORACLE将通过索引范围查询的方式查询LODGING_PK
      由于索引范围查询将返回一组值，它的效率就要比索引唯一扫描低一些

    例2
      SELECT LODGING
      FROM LODGING
      WHERE MANAGER = 'BILL GATES';

      这个SQL的执行分两步，LODGING$MANAGER的索引范围查询（得到所有符合条件记录的ROWID），通过ROWID访问表得到LODGING列的值
      由于LODGING$MANAGER是一个非唯一性的索引，数据库不能对它执行索引唯一扫描

  WHERE子句中，如果索引列所对应的值的第一个字符由通配符（WILDCARD）开始，索引将不被采用
    SELECT LODGING
    FROM LODGING
    WHERE MANAGER LIKE '％HANMAN';

  在这种情况下，ORACLE将使用全表扫描

14.避免在索引列上使用计算
  WHERE子句中，如果索引列是函数的一部分，优化器将不使用索引而使用全表扫描
  例如：
    低效
    SELECT …
    FROM DEPT
    WHERE SAL * 12 > 25000;

    高效
    SELECT …
    FROM DEPT
    WHERE SAL > 25000/12;

  请务必注意，检索中不要对索引列进行处理，如：TRIM，TO_DATE，类型转换等操作，破坏索引，使用全表扫描，影响SQL执行效率

15.避免在索引列上使用IS NULL和IS NOT NULL
  避免在索引中使用任何可以为空的列，ORACLE将无法使用该索引
  对于单列索引，如果列包含空值，索引中将不存在此记录；
  对于复合索引，如果每个列都为空，索引中同样不存在此记录。如果至少有一个列不为空，则记录存在于索引中

  如果唯一性索引建立在表的A列和B列上，并且表中存在一条记录的A,B值为(123,null)，
  ORACLE将不接受下一条具有相同A,B值（123,null）的记录插入
  如果所有的索引列都为空，ORACLE将认为整个键值为空，而空不可能等于空，因此你可以插入1000条具有相同键值的记录，当然它们都是空！
  因为空值不存在于索引列中，所以WHERE子句中对索引列进行空值比较将使ORACLE停用该索引

  低效（索引失效）
  SELECT …
  FROM DEPARTMENT
  WHERE DEPT_CODE IS NOT NULL

16.使用UNION-ALL和UNION
  当SQL语句需要UNION两个查询结果集合时，这两个结果集合会以UNION-ALL的方式被合并，然后在输出最终结果前进行排序
  如果用UNION ALL替代UNION，这样排序就不是必要了，效率就会因此得到提高

  需要注意的是，UNION ALL将重复输出两个结果集合中相同记录，因此还是要从业务需求分析使用UNION ALL的可行性

关于索引下列经验请参考:
1).如果检索数据量超过30%的表中记录数，使用索引将没有显著的效率提高
2).在特定情况下，使用索引也许会比全表扫描慢，但这是同一个数量级上的差距；而通常情况下，使用索引比全表扫描要快几倍乃至几千倍！

其他具体内容请参考《ORACLE SQL性能优化系列》

17.使用PrepareStatement
在同一个方法中，当循环使用SQL文时，为了提高性能，
请使用PreparedStatement。注意，
仅限使用于少数的模块。
方法如下：

? PreparedStatement stmt
　　　= conn.prepareStatement("select a from TABLE_A where b=? c=?");

　for(?? ){
???? stmt.setInt(1, varB);　　　　　
???? stmt.setString(2, varC);　　　 　
? 　 ResultSet rst = stmt.executeQuery();

　}

如何选择 Web 开发框架
开发框架的选择，始终是个仁者见仁、智者见智的事情。尤其是 Web 层的开发框架，数量非常多，而且各有特色，如： Struts 、 WebWork 、 Spring MVC 、 Tapestry 、 JSF 、 WebPage3.0…… 等等。
下面先来看看为什么要使用 Web 开发框架

一：使用框架的必然性
框架，即 framework 。其实就是某种应用的半成品，把不同应用程序中有共性的一些东西抽取出来，做成一个半成品程序，这样的半成品就是所谓的程序框架。
软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。这样每次开发就不用白手起家，而是可以在这个基础上开始搭建。
使用框架的最大好处：减少重复开发工作量、缩短开发时间、降低开发成本。同时还有其它的好处，如：使程序设计更合理、程序运行更稳定等。基于这些原因，基本上现在在开发中，都会选用某些合适的开发框架，来帮助快速高效的开发应用系统。
了解了使用框架的必然性，下面来看看如何选择，当然我们的话题集中在 Web 层的开发框架。在谈这个问题之前，先来看看我们在 Web 开发中究竟需要做些什么工作：

二： Web 层开发的工作
在 J2EE 开发中，分层是基本的思想， 3 层架构或者多层架构早已深入人心，在这里我们就把目光集中到 Web 层，看看到底 Web 层开发做了那些工作：
1 ：数据展示
Web 层需要从逻辑层获取需要展示的数据，然后以合理的方式在页面进行展示
2 ：人机交互
用户需要从界面上输入数据，在界面上进行按钮点击，进而触发事件，标准的事件驱动模型，然后跟后台进行数据交换，出现新的界面。
3 ：收集数据，调用逻辑层接口
Web 层收到用户的事件请求，需要调用相应的逻辑层接口来进行处理， Web 层是不会有任何逻辑处理的。调用逻辑层接口，需要传递参数，这时需要收集用户在界面上输入的数据，然后进行组织，组织成为逻辑层接口需要的数据封装形式（通常都是 ValueObject ）。
4 ：根据逻辑层的数据来重新展示页面
逻辑层处理完了，需要返回数据或信息到界面上。这个时候 Web 层需要根据返回的值选择合适的页面，然后展示这些数据或者信息。

从上面可以看出， Web 层开发的主要工作集中在展示上，也就是图形用户界面。这一部分是用户直观感受应用程序的窗口，也是用户要求最多的地方，其表现形式也是最丰富的。

三： Web 层开发的步骤
下面再来总结一下 Web 层开发的大致步骤（也就是需要开发人员做的工作）：
注意：这里讨论的 Web 层开发，是不使用任何开发框架时候的开发。

1 ：写页面 Html ，到底有哪些数据需要在界面上表现
2 ：每个数据的具体表现形式，如：有的需要表现成为下拉列表，有的需要表现成为单选按钮等。
3 ：界面表现形式的逻辑布局，所谓逻辑布局是指某些数据的表现形式应该放在前面，某些应该放在后面；某些放在上面，某些放在下面。如：某个请假申请的业务，有请假开始时间和结束时间，很明显开始时间的表现就应该排在结束时间的前面。而美工是负责最后页面的美观，一般美工不能动界面的逻辑布局。
4 ：完成前面 3 步，页面的表现形式的大致模样就有了，下面需要来做功能性的开发。第一个就是这些表现形式的值的来源，如：下拉列表显示的值从什么地方来。值的来源方式很多，有数据库中来、固定值、某断程序运行的中间结果、前面页面传递过来等等，当然典型的还是来自数据库。
好了，确定了值的来源，开发人员就要写代码来获取这些值，然后把这些值赋值到对应的表现形式里面。
5 ：还有一些比较特殊，也就是真实操作的是一类值，但是在界面上显示的是另一类值，比如：数据库中有用户编号，到了界面上就得显示用户姓名，但是所有的操作都是要操作用户编号的。我们把这种情况分做：真实值和表现值，他们有一定的内在联系。这些都是要开发人员去转化和维护的。
6 ：接下来就应该开发功能性的事件响应了。用户点击了某个按钮或者触发了某个事件，首先是客户端：数据检测、客户端事件处理；然后提交到服务端，服务端要获取到客户端提交的数据，然后调用相应的逻辑层接口来响应。当然如何写逻辑层的实现这里就不去谈论了。
7 ：逻辑层执行完过后，返回数据和信息到 Web 层，开发人员还需要写代码去处理，选择哪个页面来显示，如何显示这些数据和信息等。
8 ：在整个交互的过程中，还必须考虑到如何控制权限，如：某些数据不能显示，某些数据不能编辑等等；同样还需要考虑到消息的配置和国际化等等。这些功能起源于逻辑层，但是实际的控制要到 Web 层，这些都需要开发人员来控制。
9 ：完成了上面的开发步骤，页面基本的功能开发就告一段落，接下来开发人员需要考虑页面美观的问题了。大家可能会说： “ 不是有美工吗，还需要开发人员干什么？ ” 。事实上美工多半只能出一个静态页面的美化模版，美工对于一推 Java 代码和 Html 的混杂物，多半是没有办法的，更不要说还有一些内容是动态生成的，美工就更不可能搞定了。还是得开发人员上阵，按照美工给的模版，开始添加 Css ： class 、 id 、 style……
10 ：完成上面的开发，基本页面的开发工作就完成了，最后的一个步骤就是把各个页面有机的组织起来，开发应用程序的整体应用导航框架，通常就是菜单，然后把各个功能页面跟菜单结合起来，形成一个完整的应用。

在这里我们省略了开发期反复的调试过程，仅总结开发的步骤。

四：选择 Web 开发框架的目的
了解了如果没有框架，我们需要做的工作，这对选择框架有非常大的帮助。
框架，直白点说，就是一个半成品，能够帮我们做一些事情的半成品。
框架的选择，就是看哪个框架最合适，从而减少开发的工作量，提高开发的效率和质量，并有效减少维护的工作量，最终达到节约综合开发成本，获取更多的收益。

五：选择 Web 开发框架的标准
声明：这里所谈的选择 Web 开发框架的标准，只是我们的总结和一家之言，并不是放之四海而皆准的真理，请根据您的体会客观的看待我们的总结。
另外：我们这里更多的讨论业务功能性应用程序的 Web 开发框架。
1 ：选择能够对我们的开发过程提供更多、更好帮助的 Web 开发框架
2 ： Web 开发框架的学习一定要简单，上手一定要快，没有什么比使用能得到更深的体会。那些动不动就需要半个月或者一个月学习周期的框架，实在是有些恐怖。
3 ：一定要能得到很好的技术支持，在应用的过程中，或多或少都会出现这样或者那样的问题，如果不能很快很好的解决，会对整个项目开发带来影响。一定要考虑综合成本，其实这是目前应用开源软件最大的问题，碰到问题除了死肯文档就是查阅源代码，或者是网上搜寻解决的办法，通常一个问题就会导致 1-2 天的开发停顿，严重的甚至需要一个星期或者更长，一个项目有上这么几次，项目整体的开发成本嗖嗖的就上去了。
4 ： Web 开发框架结合其他技术的能力一定要强，比如：在逻辑层要使用 Spring 或者 Ejb3 ，那么 Web 开发框架一定要能很容易，很方便的与它们进行结合。
5 ： Web 开发框架的扩展能力一定要强。在好的框架都有力所不及的地方，这就要求能很容易的扩展 Web 开发框架的功能，以满足新的业务需要。同时要注意扩展的简单性，如果扩展框架的功能代价非常大，还不如不用呢。
6 ： Web 开发框架最好能提供可视化的开发和配置，可视化开发对开发效率的提高，已经得到业界公认。
7 ： Web 开发框架的设计结构一定要合理，应用程序会基于这个框架，框架设计的不合理会大大影响到整个应用的可扩展性。
8 ： Web 开发框架一定要是运行稳定的，运行效率高的。框架的稳定性和运行效率直接影响到整个系统的稳定性和效率。
9 ： Web 开发框架一定要能很好的结合目前公司的积累。在多年的开发中已有了很多积累，不能因为使用 Web 开发框架就不能再使用了，那未免有些得不偿失。
10 ：选择开发框架另外要注意的一点就是：任何开发框架都不可能是十全十美的，也不可能是适应所有的应用场景的，也就是说任何开发框架都有它适用的范围。所以选择的时候要注意判断应用的场景和开发框架的适用性。

Struts 应用

编者按：当作者 Chuck Cavaness（著有《Programming Jakarta Struts》一书）所在的网络公司决定采用Struts框架之后，Chuck曾经花费了好几个月来研究如何用它来构建公司的应用系统。本文叙述的正是作者在运用Struts过程中来之不易的若干经验和心得。如果你是个负责通过jsp和servlet开发Web应用的Java程序员，并且也正在考虑采用基于Struts的构建方法的话，那么你会在这里发现很多颇有见地同时也很有价值的信息。

1. 只在必要的时候才考虑扩展Struts框架

一个好的framework有很多优点，首先，它必须能够满足用户的可预见的需求。为此 Struts为Web 应用提供了一个通用的架构，这样开发人员可以把精力集中在如何解决实际业务问题上。其次，一个好的framework还必须能够在适当的地方提供扩展接口，以便应用程序能扩展该框架来更好的适应使用者的实际需要。

如果Struts framework在任何场合，任何项目中都能很好的满足需求，那真是太棒了。但是实际上，没有一个框架声称能做到这一点。一定会有一些特定的应用需求是框架的开发者们无法预见到的。因此，最好的办法就是提供足够的扩展接口，使得开发工程师能够调整struts来更好的符合他们的特殊要求。

在Struts framework中有很多地方可供扩展和定制。几乎所有的配置类都能被替换为某个用户定制的版本，这只要简单的修改一下Struts的配置文件就可以做到。

其他组件如ActionServlet和 RequestProcessor 也能用自定义的版本代替. 甚至连Struts 1.1里才有的新特性也是按照扩展的原则来设计的。例如，在异常处理机制中就允许用户定制异常处理的句柄，以便更好的对应用系统发生的错误做出响应。

作为框架的这种可调整特性在它更适合你的应用的同时也在很大的程度上影响了项目开发的效果。首先，由于您的应用是基于一个现有的成熟的、稳定的framework如Struts，测试过程中发现的错误数量将会大大减少，同时也能缩短开发时间和减少资源的投入。因为你不再需要投入开发力量用于编写基础框架的代码了。

然而, 实现更多的功能是要花费更大的代价的。我们必须小心避免不必要的滥用扩展性能， Struts是由核心包加上很多工具包构成的，它们已经提供了很多已经实现的功能。因此不要盲目的扩展Struts框架，要先确定能不能采用其他方法使用现有的功能来实现。 在决定编写扩展代码前务必要确认Struts的确没有实现你要的功能。否则重复的功能会导致混乱将来还得花费额外的精力清除它。

2. 使用异常处理声明

要定义应用程序的逻辑流程，成熟的经验是推荐在代码之外，用配置的方法来实现，而不是写死在程序代码中的。在J2EE中，这样的例子比比皆是。从实现EJB的安全性和事务性行为到描述JMS消息和目的地之间的关系，很多运行时的处理流程都是可以在程序之外定义的。

Struts 创建者从一开始就采用这种方法，通过配置Struts的配置文件来定制应用系统运行时的各个方面。这一点在版本1.1的新特性上得到延续，包括新的异常处理功能。在Struts framework以前的版本中，开发人员不得不自己处理Struts应用中发生的错误情况。在最新的版本中，情况大大的改观了，Struts Framework提供了内置的一个称为 ExceptionHandler 的类， 用于系统缺省处理action类运行中产生的错误。这也是在上一个技巧中我们提到的framework许多可扩展接口之一。

Struts缺省的 ExceptionHandler类会生成一个ActionError对象并保存在适当的范围（scope）对象中。这样就允许JSP页面使用错误类来提醒用户出现什么问题。如果你认为这不能满足你的需求，那么可以很方便的实现你自己的ExcepionHandler类。

具体定制异常处理的方法和机制

要定制自己的异常处理机制，第一步是继承org.apache.struts.action.ExceptionHandler类。这个类有2个方法可以覆盖，一个是excute()另外一个是storeException(). 在多数情况下，只需要覆盖其中的excute()方法。下面是ExceptionHandler类的excute()方法声明：



正如你看到的，该方法有好几个参数，其中包括原始的异常。方法返回一个ActionForward对象，用于异常处理结束后将controller类带到请求必须转发的地方去。

当然您可以实现任何处理，但一般而言，我们必须检查抛出的异常,并针对该类型的异常进行特定的处理。缺省的，系统的异常处理功能是创建一个出错信息，同时把请求转发到配置文件中指定的地方去。 定制异常处理的一个常见的例子是处理嵌套异常。假设该异常包含有嵌套异常，这些嵌套异常又包含了其他异常，因此我们必须覆盖原来的execute()方法，对每个异常编写出错信息。

一旦你创建了自己的ExceptionHandler 类，就应该在Struts配置文件中的部分声明这个类，以便让Struts知道改用你自定义的异常处理取代缺省的异常处理.

可以配置你自己的ExceptionHandler 类是用于Action Mapping特定的部分还是所有的Action对象。如果是用于Action Mapping特定的部分就在 元素中配置。如果想让这个类可用于所有的Action对象,可以在 元素中指定。例如，假设我们创建了异常处理类CustomizedExceptionHandler用于所有的Action类, 元素定义如下所示：



在 元素中可以对很多属性进行设置。在本文中，最重要的属性莫过于handler属性, handler属性的值就是自定义的继承了ExceptionHandler类的子类的全名。 假如该属性没有定义，Struts会采用自己的缺省值。当然，其他的属性也很重要，但如果想覆盖缺省的异常处理的话，handler无疑是最重要的属性。

最后必须指出的一点是，你可以有不同的异常处理类来处理不同的异常。在上面的例子中，CustomizedExceptionHandler用来处理任何java.lang.Exception的子类. 其实，你也可以定义多个异常处理类，每一个专门处理不同的异常树。下面的XML片断解释了如何配置以实现这一点。



在这里，一旦有异常抛出，struts framework将试图在配置文件中找到ExceptionHandler，如果没有找到，那么struts将沿着该异常的父类链一层层往上找直到发现匹配的为止。因此，我们可以定义一个层次型的异常处理关系结构，在配置文件中已经体现了这一点。

3. 使用应用模块（Application Modules）

Struts 1.1的一个新特性是应用模块的概念。应用模块允许将单个Struts应用划分成几个模块，每个模块有自己的Struts配置文件，JSP页面，Action等等。这个新特性是为了解决大中型的开发队伍抱怨最多的一个问题，即为了更好的支持并行开发允许多个配置文件而不是单个配置文件。

注：在早期的beta版本中，该特性被称为子应用（sub-applications），最近的改名目的是为了更多地反映它们在逻辑上的分工。

显然，当很多开发人员一起参加一个项目时，单个的Struts配置文件很容易引起资源冲突。应用模块允许Struts按照功能要求进行划分，许多情况已经证明这样更贴近实际。例如，假设我们要开发一个典型的商店应用程序。可以将组成部分划分成模块比如catalog（商品目录）, customer（顾客）, customer service（顾客服务）, order（订单）等。每个模块可以分布到不同的目录下，这样各部分的资源很容易定位，有助于开发和部署。图1 显示了该应用的目录结构。

图 1. 一个典型的商店应用程序的目录结构

注：如果你无需将项目划分成多个模块，Struts框架支持一个缺省的应用模块。这就使得应用程序也可以在1.0版本下创建，具有可移植性，因为应用程序会自动作为缺省的应用模块。

为了使用多应用模块功能，必须执行以下几个准备步骤：

• 为每个应用模块创建独立的Struts配置文件。

• 配置Web 部署描述符 Web.xml文件。

• 使用org.apache.struts.actions.SwitchAction 来实现程序在模块之间的跳转.

创建独立的Struts配置文件

每个Struts应用模块必须拥有自己的配置文件。允许创建自己的独立于其他模块的Action，ActionForm，异常处理甚至更多。

继续以上面的商店应用程序为例，我们可以创建以下的配置文件：一个文件名为struts-config-catalog.xml，包含catalog（商品目录）、items(商品清单)、和其它与库存相关的功能的配置信息；另一个文件名为struts- config-order.xml, 包含对order（订单）和order tracking（订单跟踪）的设置。第三个配置文件是struts-config.xml,其中含有属于缺省的应用模块中的一般性的功能。

配置Web部署描述符

在Struts的早期版本中，我们在Web.xml中指定Struts配置文件的路径。好在这点没变，有助于向后兼容。但对于多个应用模块，我们需要在Web部署描述符中增加新的配置文件的设定。

对于缺省的应用（包括Struts的早期版本），Struts framework 在Web.xml文件中查找带有config的元素 ，用于载入Action mapping 和其它的应用程序设定。作为例子，以下的XML片断展现一个典型的 元素：



注：如果在现有的 元素中找不到"config"关键字，Struts framework将缺省地使用/WEB/struts-config.xml

为了支持多个应用模块(Struts 1.1的新特性)，必须增加附加的 元素。与缺省的 元素不同的是，附加的 元素与每个应用模块对应，必须以config/xxx的形式命名，其中字符串xxx代表该模块唯一的名字。例如，在商店应用程序的例子中， 元素可定义如下（注意粗体字部分）：

第一个 元素对应缺省的应用模块。第二和第三个元素分别代表非缺省应用模块catalog 和 order。

当Struts载入应用程序时，它首先载入缺省应用模块的配置文件。然后查找带有字符串config/xxx 形式的附加的初始化参数。对每个附加的配置文件也进行解析并载入内存。这一步完成后，用户就可以很随意地用config/后面的字符串也就是名字来调用相应的应用模块。

多个应用模块之间调用Action类

在为每个应用模块创建独立的配置文件之后，我们就有可能需要调用不同的模块中Action。为此必须使用Struts框架提供的SwitchAction类。Struts 会自动将应用模块的名字添加到URL,就如Struts 自动添加应用程序的名字加到URL一样。应用模块是对框架的一个新的扩充，有助于进行并行的团队开发。如果你的团队很小那就没必要用到这个特性，不必进行模块化。当然，就算是只有一个模块，系统还是一样的运作。

4. 把JSP放到WEB-INF后以保护JSP源代码

为了更好地保护你的JSP避免未经授权的访问和窥视， 一个好办法是将页面文件存放在Web应用的WEB-INF目录下。

通常JSP开发人员会把他们的页面文件存放在Web应用相应的子目录下。一个典型的商店应用程序的目录结构如图2所示。跟catalog （商品目录）相关的JSP被保存在catalog子目录下。跟customer相关的JSP，跟订单相关的JSP等都按照这种方法存放。



图 2.基于不同的功能 JSP 被放置在不同的目录下

这种方法的问题是这些页面文件容易被偷看到源代码，或被直接调用。某些场合下这可能不是个大问题，可是在特定情形中却可能构成安全隐患。用户可以绕过Struts的controller直接调用JSP同样也是个问题。

为了减少风险，可以把这些页面文件移到WEB-INF 目录下。基于Servlet的声明，WEB-INF不作为Web应用的公共文档树的一部分。因此，WEB-INF 目录下的资源不是为客户直接服务的。我们仍然可以使用WEB-INF目录下的JSP页面来提供视图给客户，客户却不能直接请求访问JSP。

采用前面的例子，图3显示将JSP页面移到WEB-INF 目录下后的目录结构

图 3. JSP存放在 WEB-INF 目录下更为安全

如果把这些JSP页面文件移到WEB-INF 目录下，在调用页面的时候就必须把"WEB-INF"添加到URL中。例如，在一个Struts配置文件中为一个logoff action写一个Action mapping。其中JSP的路径必须以"WEB-INF"开头。如下所示：请注意粗体部分.

这个方法在任何情况下都不失为Struts实践中的一个好方法。是唯一要注意的技巧是你必须把JSP和一个Struts action联系起来。即使该Action只是一个很基本的很简单JSP，也总是要调用一个Action，再由它调用JSP。

最后要说明的是，并不是所有的容器都能支持这个特性。WebLogic早期的版本不能解释Servlet声明，因此无法提供支持，据报道在新版本中已经改进了。总之使用之前先检查一下你的Servlet容器。

5. 使用 Prebuilt Action类提升开发效率

Struts framework带有好几个prebuilt Action类，使用它们可以大大节省开发时间。其中最有用的是org.apache.struts.actions.ForwardAction 和 org.apache.struts.actions.DispatchAction.

使用 ForwardAction

在应用程序中，可能会经常出现只要将Action对象转发到某个JSP的情况。在上一点中曾提到总是由Action调用JSP是个好习惯。如果我们不必在Action中执行任何业务逻辑，却又想遵循从Action访问页面的话，就可以使用ForwardAction，它可以使你免去创建许多空的Action类。运用ForwardAction的好处是不必创建自己的Action类，你需要做的仅仅是在Struts配置文件中配置一个Action mapping。

举个例子，假定你有一个JSP文件index.jsp ，而且不能直接调用该页面，必须让程序通过一个Action类调用，那么，你可以建立以下的Action mapping来实现这一点：

正如你看到的，当 /home 被调用时, 就会调用ForwardAction 并把请求转发到 index.jsp 页面.

再讨论一下不通过一个Action类直接转发到某个页面的情况，必须注意我们仍然使用 元素中的forward属性来实现转发的目标。这时 元素定义如下：

以上两种方法都可以节省你的时间，并有助于减少一个应用所需的文件数。

使用 DispatchAction

DispatchAction是Struts包含的另一个能大量节省开发时间的Action类。与其它Action类仅提供单个execute()方法实现单个业务不同，DispatchAction允许你在单个Action类中编写多个与业务相关的方法。这样可以减少Action类的数量，并且把相关的业务方法集合在一起使得维护起来更容易。

要使用DispatchAction的功能，需要自己创建一个类，通过继承抽象的DispatchAction得到。对每个要提供的业务方法必须有特定的方法signature。例如，我们想要提供一个方法来实现对购物车添加商品清单，创建了一个类ShoppingCartDispatchAction提供以下的方法：

那么，这个类很可能还需要一个deleteItem()方法从客户的购物车中删除商品清单，还有clearCart()方法清除购物车等等。这时我们就可以把这些方法集合在单个Action类，不用为每个方法都提供一个Action类。

在调用ShoppingCartDispatchAction里的某个方法时，只需在URL中提供方法名作为参数值。就是说，调用addItem()方法的 URL看起来可能类似于：

http://myhost/storefront/action/cart?method=addItem

其中method参数指定ShoppingCartDispatchAction中要调用的方法。参数的名称可以任意配置，这里使用的"method"只是一个例子。参数的名称可以在Struts配置文件中自行设定。

6.使用动态ActionForm

在Struts framework中，ActionForm对象用来包装HTML表格数据（包括请求），并返回返回动态显示给用户的数据。它们必须是完全的JavaBean，并继承.Struts　里面的ActionForm类，同时，用户可以有选择地覆盖两个缺省方法。

该特性能节省很多时间，因为它可以协助进行自动的表现层的验证。ActionForm的唯一缺点是必须为不同的HTML表格生成多个ActionForm 类以保存数据。例如，如果有一个页面含有用户的注册信息，另一个页面则含有用户的介绍人的信息，那么就需要有两个不同的ActionForm类。这在大的应用系统中就会导致过多的ActionForm类。Struts 1.1对此做出了很好的改进，引入了动态ActionForm类概念

通过Struts framework中的DynaActionForm类及其子类可以实现动态的ActionForm ，动态的ActionForm允许你通过Struts的配置文件完成ActionForm的全部配置；再也没有必要在应用程序中创建具体的ActionForm类。具体配置方法是：在Struts的配置文件通过增加一个 元素，将type属性设定成DynaActionForm或它的某个子类的全名。下面的例子创建了一个动态的ActionForm名为logonForm，它包含两个实例变量：username 和 password.



动态的ActionForm可以用于Action类和JSP，使用方法跟普通的ActionForm相同，只有一个小差别。如果使用普通的ActionForm对象则需要提供get 和 set方法取得和设置数据。以上面的例子而言，我们需要提供getUsername() 和 setUsername()方法取得和设置username变量，同样地有一对方法用于取得和设置password变量.

这里我们使用的是DynaActionForm，它将变量保存在一个Map类对象中，所以必须使用DynaActionForm 类中的get(name) 和 set(name)方法，其中参数name是要访问的实例变量名。例如要访问DynaActionForm中username的值，可以采用类似的代码：

String username = (String)form.get("username");

由于值存放在一个Map对象，所以要记得对get()方法返回的Object对象做强制性类型转换。

DynaActionForm有好几个很有用的子类。其中最重要的是DynaValidatorForm ，这个动态的ActionForm和Validator 一起利用公共的Validator包来提供自动验证。这个特性使你得以在程序代码之外指定验证规则。将两个特性结合使用对开发人员来说将非常有吸引力。

7. 使用可视化工具

自从Struts 1.0 分布以来，就出现了不少可视化工具用于协助创建，修改和维护Struts的配置文件。配置文件本身是基于XML格式，在大中型的开发应用中会增大变得很笨拙。为了更方便的管理这些文件，一旦文件大到你无法一目了然的时候，建议试着采用其中的一种GUI 工具协助开发。商业性的和开放源代码的工具都有不少，表1列出了可用的工具和其相关链接，从那里可以获取更多信息。

表 1. Struts GUI 工具
应用程序 性质 网址
Adalon 商业软件 http://www.synthis.com/products/adalon
Easy Struts 开放源码 http://easystruts.sourceforge.net/
Struts Console 免费 http://www.jamesholmes.com/struts/console
JForms 商业软件 http://www.solanasoft.com/
Camino 商业软件 http://www.scioworks.com/scioworks_camino.html
Struts Builder 开放源码 http://sourceforge.net/projects/rivernorth/
StrutsGUI 免费 http://www.alien-factory.co.uk/struts/struts-index.html