2022年Java软件开发规范.docx

《2022年Java软件开发规范.docx》由会员分享，可在线阅读，更多相关《2022年Java软件开发规范.docx（39页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、2022年Java软件开发规范 Java 软件开发规范 版本说明 版本 作者 日期 备注 征求版 提出初始版本，分发各相关人员 JAVA 软件开发规范 1 1 绪论 4 1.1 概述 4 1.2 优良代码的特点 4 1.3 适用范围 4 2 总体架构 4 2.1 框架概述 4 2.2 框架规范 4 2.2.1 Service 规范 5 2.2.2 Model 规范 5 2.2.3 DAO 规范 5 2.2.4 Servlet 规范 5 2.2.5 Action 规范 5 2.2.6 消息规范 错误! 未定义书签。 3 J AVA 开发规范 5 3.1 风格规范 5 3.1.1 风格概述 5 3

2、.1.2 类导入规范 6 3.1.3 缩进规范 6 3.1.4 表达式和语句规范 6 3.1.5 括号规范 6 3.1.6 空格规范 7 3.1.7 空行规范 7 3.1.8 注释规范 7 3.2 模块划分 8 3.3 包存放规范 9 3.4 命名规范 10 3.4.1 包命名规范 10 3.4.2 类 命名规范 10 3.4.3 字段命名规范 11 3.4.4 方法命名规范 11 3.5 方法编写规范 11 3.5.1 基本原则 11 3.5.2 参数规范 12 3.5.3 出口规范 12 3.5.4 留意事项 12 3.6 语句选择规范 13 3.6.1 分支语句 13 3.6.2 循环语

3、句 13 3.7 异样处理与资源回收 15 3.7.1 异样处理 15 3.7.2 资源回收 15 3.8 性能与平安 16 3.8.1 基本原则 16 3.8.2 削减重复计算 16 3.8.3 可变字符串 17 3.8.4 集合实现 17 3.8.5 对象创建与释放 18 3.8.6 代码同步 18 4 WEB 开发规范 18 4.1 书目规范 18 4.1.1 一般原则 18 4.1.2 根书目 18 4.1.3 公用资源书目 18 4.1.4 业务模块书目 19 4.1.5 文件引用规范 19 4.1.6 配置文件书目 19 4.1.7 配置文件命名 22 Spring 配置文件命名

4、22 Spring 配置文件中 Bean 的命名 22 Struts 配置文件命名 22 其他配置文件命名 22 4.2 HTML 规范 22 4.2.1 页面规范 22 4.2.2 元素 name 命名规范 23 4.2.3 元素 id 命名规范 23 JSP 规范 23 4.3.1 JSP 页面规范 23 4.3.2 JSP 编码规范 23 4.3.3 单记录页面布局规范 24 4.3.4 列表记录页面规范 25 4.3.5 数据有效性验证 26 4.3.6 特殊规定 26 4.3 平安验证 29 5 附录 29 第三方组件的运用 29 引入新的第三方组件 29 5.1 特别要求 30 5

5、.5.1 页面传值要求 30 5.5.2 常用操作类型定义 30 5.5.3 维护页面个数 30 5.5.4 数据保持 30 5.2 其它 30 5.3 错误收集 31 1 绪论 1.1 概述 本规范的目的是使本公司能以标准的、规范的方式设计和编码。通过建立开发规范，使每个开发人员养成良好的开发风格和习惯；提高程序的牢靠性、可读性、可维护性和一样性等，提高程序员的开发水平，增进团队间的沟通，并保证软件产品的质量。 代码虽然是给机器运行的，但却是给人读的。 最基本的原则是运用常识。当找不到任何规则或指导方针或者规则明显不适用时，运用常识并核实本规范的基本原则。这条规则比其它全部规则都重要，记住一

6、点，常识必不行少。当出现该状况时，应当刚好收集并提交，以便完善本规范。 1.2 优良 代码的特点 任何的软件设计中，都离不开编程实现。在软件实现中，除了程序架构设计、数据结构设计、算法的设计以外，还有详细的代码的编写规范问题。 好的代码应当具有以下的特征： 精确性：保证程序运行稳定、正确，不简单出错； 简洁性：程序代码简单管理； 清楚性：程序简单理解，无论对人还是计算机； 普遍性：在很广泛的状况下都能工作的很好，也简单做修改以适应新出现的状况； 1.3 适用 范围 本规范适用于XXX 经营分析系统下全部有软件项目、产品等的设计、开发以及维护、升级等。 本公司全部从事 经营分析系统产品开发的软件

7、开发人员在整个软件开发过程中必需遵循此规范。 2 总体架构 2.1 框架 概述 2.2 框架 规范 XXX 经营分析系统下全部的模块和子系统都应当运用 SSH 或 Seam 框 架 进 行 开 发 （ 具 体 使 用 的Sturts,Spring,Hibernate 版本在 Maven 的 Master 项目中定义）。 XXX 经营分析系统下全部的模块和子系统的开发都应当运用 JDK1.5.*版本，不能运用JDK1.6.*版本。 2.2.1 Service 规范 只完成业务逻辑操作，数据库事务在此层进行限制。 Struts Form 类不能作为参数传入 Service 类中。 2.2.2 Mo

8、del 规范 只有属性及属性的 Getter 和 Setter 方法，以及必要的 euqals 和 hashcode 方法。 2.2.3 DAO 规范 只做存取、更新、删除数据的操作，SQL 语句应当出现在此层的类中。 2.2.4 Servlet 规范 只做恳求转发、结果返回的工作，逻辑及数据操作放到 Service 及 DAO 层。 2.2.5 Action 规范 同 Servlet，只做恳求参数接收、恳求转发、结果转换、结果返回的工作。 3 Java 开 发 规范 本部分着重 B/S 结构中 Server 端 Java 代码的规范。 3.1 风格规范 3.1.1 风格概述 在实际的开发中，

9、由于项目期限等缘由，尽管已经有初步的开发规范，但在项目后期经常失控，为了赶进度，开发人员渐渐养成了一些不良的习惯。命名随意、注释不清楚、导入不运用的类、定义不运用的变量、方法存在不须要的参数、方法命名与方法实现功能不一样、程序缩进不一样等。这些都是须要规范的地方。 好的程序书写规范比随意的书写规范更清楚、错误更少、更易修改。所以，一起先就要留意运用好的编写风格。好的程序设计风格就犹如好的文章，不仅要求语句顺畅，而且段落分明，结构紧凑。不仅排版要清楚，标点符号正确运用，而且重点要突出，中心明确。 让我们从这些基本的编程技术基础上入手，改正以前的不良习惯，逐步提高应用交付的质量。 3.1.2 类

10、导入规范 在 import 须要用到的类时，尽量少用 import *；而应当详细指明须要导入的类，利于代码阅读，知道用到了详细的什么类。同时，由于我司目前开发的应用为打包，所以还不存在较大问题，今后开发的应用进一步规范化之后，打包时会将*所涉及到的类全部导入。 导入须要用到的类应当根据肯定的依次导入，不能随意写，此处规定，导入依次如下，且前后类别之间以空行隔开： Java 标准包类 Java 扩展包类 第三方组件包类 公司基础库包类 业务系统自身基础包类 3.1.3 缩进 规范 源码缩进不仅仅使程序更美观，而且也使程序结构更清楚、易读。采纳统一的 Tab 缩进方式。各集成开发工具应当将 Ta

11、b 键设为 4 个空格。在类的定义、方法体的起先以及 if、for、do、while、switch、case 语句中的程序都要采纳如上的缩进方式。 3.1.4 表达式和语句规范 表达示和语句是程序中运用最多的基本语法，也是构成程序逻辑的基本要素，它们的不合理运用很大地影响了程序的清楚性、简洁性。 3.1.5 括号 规范 在表达示中，因为算术运算符，关系运算符和逻辑运算符的优先级别一般很难记清，因此规定采纳括号（）显式划分计算的优先级，解除二义性。 在条件推断中，无论执行语有几条，都应当以大括号括起来，否则简单引入 Bug。 在困难的条件推断中必需要运用括号把各个条件分隔开来。 3.1.6 空格

12、规范 关键词和操作符之间加空格； 方法名之后不要留空格，紧跟左括号（，以与关键字区分； 方法中参数之间夹空格； 赋值操作符、比较操作符、算术操作符、逻辑操作符、位与操作符，如=、+= >=、<=、+、%、|、<<,等二元操作符的前后应当加空格； 一元操作符如!、+、-、（地址运算符）等前后不加空格； 对于表达式比较长的 for 语句和 if 语句，为了紧凑起见可以适当地去掉一些空格，如 for 和 if )。 3.1.7 空行规范 包命名的行和后续导入的类之间加一个空行； 按 3.1.2 规范导入的类之间加空行； 在导入类和类注释之间加空行； 方法和方法之间加空行； 相

13、对独立的程序块与块之间加空行； 较长的语句、表达式等要分成多行书写（是否须要换行可以以是否要拖到左右滚动条才能看到整行代码为准，即须要拖到滚动条才能望见整行代码的须要进行换行处理）； 划分出的新行要进行适当缩进，使排版整齐，语句可读。 长表达式要在低优先级操作符处划分新行，操作符放在新行之首； 循环、推断等语句中若有较长的表达式或语句，则要进行适当划分； 方法参数较长，进行适当的划分； 不允许把多个短语句写在一行中，即一行只写一条语句； 方法或过程的起先、结构的定义及循环、推断等语句中的代码都要采纳缩进风格。 程序的分界符和应独占一行并且位于同一列，同时与引用它们的语句左对齐； 3.1.8 注

14、释规范 为便于维护，对程序应当给出适当的注释。没有注释也就意味着很快就会被抛弃，因为可能没人能懂。注释应当符合 JavaDOC 的标准，这样编译器不会给出警告，否则有的编译器可能会给出警告。 类注释 对类和接口应当加以注释，对该类作一个简洁功能描述，同时还可以标注其他内容：如公司名称，起先编写日期等，但作者必需标注上，便利在出现问题时由原作者负责说明。注 释示例如图 3.1 所示。 图 3.1：类注释示例 方法注释 应当对方法进行注释。注释必需含功能描述，参数描述，返回值描述。假如参数较为困难，或者怕遗忘，则具体说明每个参数的作用、取值范围及相互间的关系。方法注释示例如图 3.2 所示。 图

15、3.2：方法注释示例 代码注释 对于较长或逻辑较负责的代码段，都应当添加注释，注释主要说明为什么要这样做以及都做了些什么工作。代码注释示例见图 3.3 所示： 图 3.3：代码注释示例 3.2 模块划分 合理的模块划分能提高我司按模块提交项目的实力。在一个项目起先之前，应当进行合理的模块划分，各个包之间不能有循环引用的关系。划分之后任一模块的业务代码应当仅依靠于下述包： Java 标准包 Java 扩展包 第三方组件包 公司基础库包 业务系统基础包 除此之外，不应当再导入其他类，如有导入，则说明模块划分可能不够合理。设计人员在设计之初应当对此进行全局考虑。 3.3 包存放规范 尽管 Java

16、支持未命名包，但为让程序显得美观、清楚直观，程序应当放到相应的包下。我公司开发的程序应当放到 com.XXX 包或其子书目下。 此处规定，禁止写未命名包的程序，希望大家遵守。 Java 包命名规范如下： 包名 运用描述 com.XXX.biframe AIOmniVison-tech 部门运用的根包，Tech 部门全部的类都放在此包下 com.XXX.biapp AIOmniVison-app 部门运用的根包，App 部门全部的类都放在此包下 com.XXX.bistudio 存放构建在 Eclipse 基础上的经分开发工具的代码 com.XXX.util 存放在 biframe 及 biap

17、p 中都须要运用的工具类 com.XXX.biframebiapp.<模块名> 相应的模块应当在根包下都有一个子包，每个模块在根包下有且只能有一个子包 com.XXX.biframebiapp.<模块名>.action 存放模块的 action 类，假如模块中的子模块较多，可以在此书目下再建子模块包 com.XXX.biframebiapp.<模块名>.dao 存放模块的 dao 接口类，假如模块中的子模块较多，可以在此书目下再建子模块包 com.XXX.biframebiapp.<模块名>.dao.impl 存放模块的 dao 实现类，假如模块

18、中的子模块较多，可以在此书目下再建子模块包 com.XXX.biframebiapp.<模块名>.model 存放模块中 Hibernate 运用的数据对象映射类及.hbm.xml 配置文件 com.XXX.biframebiapp.<模块名>.service 存放模块的 Service 接口类，假如模块中的子模块较多，可以在此书目下再建子模块包 com.XXX.biframebiapp.<模块名>.service.impl 存放模块的 Service 实现类，假如模块中的子模块较多，可以在此书目下再建子模块包 com.XXX.biframebiapp.&l

19、t;模块名>.util 存放模块中运用的工具类 com.XXX.biframebiapp.<模块名>.servlet 存放模块中运用的Servlet类（不举荐运用Servlet来实现限制转发或逻辑处理） 3.4 命名规范 命名采纳英文命名，禁止采纳中文汉语拼音命名，命名采纳大小写混合，提高可读性。命名应当能顾名思义，能够正确表达出想要表达的意思。 3.4.1 包命名规范 包表示一对类的共同含义，可以对应应用开发的模块，必需以名词命名，必需全部实行小写字母形式，并具备规定的层次。 如 com.XXX.report 包表示出现在该包内的类都是为报表服务的。 3.4.2 类 命名规

20、范 类和接口表示一类对象，必需以名词命名。类名的第一个字母必需大写，类名如由多个单词构成，则每个单词的头一个字母必需大写。如消息管理器命名为MessageManager。 为统一起见，对我司的框架中出现的五种类做出进一步规定，如下： Action 类 Action 类必需以Action结尾，如 AmsAssetsCheckHeaderAction； Dao 类 Dao 接口类必需以I大写字母开头，以Dao字母结尾，如 IAmsAssetsCheckHeaderDao； Dao 实现类必需以Impl字母结尾，如 AmsAssetsCheckHeaderDaoImpl； Service 类 Ser

21、vice 接 口 类 必 须 以 I 大 写 字 母 开 头 ， 以 Service 字 母 结 尾 ， 如IAmsAssetsCheckHeaderService； Service 实现类必需以Impl字母结尾，如 AmsAssetsCheckHeaderServiceImpl； Servlet 类 Servlet 类必需以Servlet结尾，如 AmsAssetsCheckHeaderServlet； Model 类 Model 类以表名为准，如 AmsAssetsCheckHeader。 上述五个示例类对应的表 AMS_ASSETS_CHECK_HEADER，类名和表名的对应关系为：表名

22、第一个字母大写不变，后续字母变为小写，直到遇到下划线_，下划线_不出现在类名中，下划线_紧跟的字母保持大写不变，后续字母又变为小写，以此类推。 对于不须要单独维护或查询表，不须要写对应的 Servlet 类，但其他三类应当供应，由其他的 DAO 类调用。 3.4.3 字段命名规范 类中的字段表示类的一个属性或标记，同样也必需以名词命名。字段名的第一个字母必需 为 小 写 ， 其 余 字 母 和 表 字 段 映 射 关 系 同 类 名 和 表 名 的 映 射 关 系 。 如 表AMS_ASSETS_CHECK_HEADER 的字段盘点工单号TRANS_NO则在上述四类中都必需以transNo出现

23、。 特殊规定：Web 页面表单域名与 Model 对象属性名相同。 对应关系 定义如表 3.1 ： 所示： 表 3.1：命名示例 表单域名 Model 属性名 数据库字段名 transNo transNo TRANS_NO 3.4.4 方法命名规范 方法表示一次操作，因此必需以动词形式命名。方法名第一个字母实行小写形式，其余字母同类的命名规则。 Model 类中方法名和字段名的对应关系为 JavaBean 中的规则，此处不再赘述。 3.4.5 变量命名规范 变量命名规范参与XXX-JAVA 编码规范.doc中3.变量属性规范及4.局部变量规范。 3.5 方法 编写 规范 3.5.1 基本原则

24、方法是 Java 的基本功能单元，设计的微小缺点很简单导致该方法被错用，所以仅方法功能正确是不够的。 一个方法应当只完成一项功能。 对于公用接口外的方法，应当尽可能缩小其可见性，避开用一个类实例去访问其静态变量和方法。当一个方法被调用之后，方法所在类应当反馈出本次调用是胜利还是失败，假如被调用方法不能反馈结果，则同一类中其他方法应当供应。 3.5.2 参数规范 禁止方法供应超过四个的参数。假如的确须要更多参数，则用参数建立新的值对象，以此对象做参数。 参数类型和返回值尽量接口化，以屏蔽详细的实现细微环节，提高程序的可扩展性。 在方法的入口处对参数进行有效性检查。 许多程序错误是由非法参数引起的

25、。良好的编程典范规定：当编写一个方法时，必需验证全部传递进来的参数，假如任何一个参数不合乎要求，就应当明确地引发一个异样。boolean 参数不应当检查。 3.5.3 出口规范 对于有返回值的方法，建议最多只供应 2 个出口（一个是推断参数有效性后可以干脆返回，另一个是只能在方法体最终有返回），不好的代码如图 3.3 所示，好的代码如图 3.4 所示。 图 3.3：方法出口错误示例 图 3.4：方法出口正确示例 3.5.4 留意事项 方法的规模尽量限制在 200 行以内。超过 200 行则多半存在可以独立的逻辑单元， 则可以将其抽取出去另写方法； 一个方法仅完成一件功能； 为简洁功能编写方法；

26、 方法的功能应当是可预料的，也就是只要输入数据相同就应产生同样的输出； 尽量不要编写依靠于其他方法内部实现的方法； 避开设计多参数方法，不运用的参数从接口中去掉；参数多时将之作为新对象的字段，以对象形式传入； 用注释具体说明每个参数的作用、取值范围及相互间的关系； 检查全部参数输入的有效性； 检查全部非参数输入的有效性，如数据文件、公共变量等。 方法名应精确描述方法的功能； 方法的返回值要清晰、明白，让运用者不简单忽视错误状况。 削减方法本身或方法间的递归调用； 3.6 语句选择规范 3.6.1 分支语句 分支语句有 if，switch 两种。if 语句多用于分支较少的状况，switch 语句

27、正好相反。当分支较多时，采纳 if 语句显得冗长，建议采纳 switch 语句。 3.6.2 循环语句 Java 循环语句中，for 语句运用频率最高，while 语句其次，do 语句很少用，可依据自己熟识程度选用，但应当考虑效率问题。在循坏次数不太多时，三种语句循环效率无明显差别；当循环次数较大时，效率最高的是 do 循坏，其次是 for 循坏，最终是 while 循坏。 多重循环效率问题 在多重循环中，假如有可能，应当将最长的循环放在最内层，最短的循环放在最外层，以削减 CPU 跨切循环层的次数。示例 3-5 的效率比示例 3-6 的高。 图 3.5：效率高的多重循环 图 3.6：效率低的

28、多重循环 循环内逻辑推断问题 假如循环体内存在逻辑推断，并且循环次数很大，宜将逻辑推断移到循环体外面。示例3-7 的程序比示例 3-8 多执行了 N-1 次逻辑推断。并且由于前者老要进行逻辑推断，打断了循环流水线作业，使得编译器不能对循环进行优化处理，降低了效率。假如 N 特别大，应当采纳示例 3-8 的写法；假如 N 特别小，两者效率差别并不明显，采纳示例 3-7 的写法可使程序更加简洁。 图 3-7：低效率逻辑推断 图 3-8：高效率逻辑推断 特别规定 如无必要，不应当在 for 循环体内修改循环变量，防止 for 循环失去限制。 3.7 异样 处理与资源回收 3.7.1 异样处理 异样处

29、理的基本思想是只对错误进行处理，如数据库操作、文件操作中的错误以及有限性资源耗尽等。 捕获异样是为了处理它，不要捕获后却不做任何处理。假如不想处理，则应当申明方法抛出相应异样，由调用者处理。 假如对不同的异样有不同的处理方式，则应当运用多个 catch 语句捕获异样，并分别进行处理。 一个方法申明抛出的异样个数应当最小化，最好只抛出一个异样。 在 SSH 架构开发中，异样处理流程应当是这样的： l Dao 层不处理错误，干脆把错误抛出给调用它的 Service 层，Dao 类的方法必需要申明会抛出异样； l Service 层负责捕获及处理异样，把技术异样信息转换为用户能理解逻辑异样信息，并抛

30、出包含此异样信息的业务逻辑异样类； l Action 层负责捕获 Service 层抛出的业务逻辑异样类，并取出业务逻辑异样信息存储在 Request 或 Session 对象中； l 呈现层（JSP）负责展示存储在 Request 或 Session 对象中的业务逻辑异样信息，可以通过弹出窗体显示、在错误页面上显示或在当前页面上显示； 在 com.XXX.biframe.exception 包下定义了各种常用的异样基类，经营分析系统中各模块或子系统中定义的业务逻辑异样类应当从ServiceException类或BaseRuntimeExcepton类处继承。 3.7.2 资源回收 有限性资源

31、运用完毕后，应当马上释放。如数据库连接，I/O 操作等。无论程序是否发生异样，资源都应当得到回收。 回收资源的代码应当位于 finally 子句内，以保证资源得到释放，禁止与正常的业务处理代码混在一块。 假如类中有限性资源是全局性共享资源，则类还应当供应 finalize 方法，由 JVM 在资源回收的时候调用 finalize 方法，做最终释放。 异样处理与资源回收代码示例如图 3.9 所示。 图 3.9：异样与资源释放示例 3.8 性能与平安 3.8.1 基本原则 程序在满意功能的状况下，应当尽量提高运行性能。 3.8.2 削减重复计算 假如一个代价昂贵的计算或查询多次出现，那么就只在一个

32、地方实现，并记录结果。这 样会避开无谓的重复计算与查询工作。示例 3.10 枚循环一次都会计算一次 size，而 3.11 只计算一次，计算越困难性能牺牲就越大。 图 3.11：重复计算示例 图 3.12：一次计算示例 3.8.3 可变字符串 处理可变字符串时，尽量运用 StringBuffer 类而非 String 类。由 StringBuffer 对象完成大部分工作，完成后将之转换为须要的 String 对象。在 1.5 及以上的 JDK 版本中可以选中运用StringBuilder 类，其效率比 StringBuffer 更高，但是线程担心全的。 3.8.4 集合 实现 禁止运用 Vec

33、tor 和 HashTable 等旧集合实现，在新的系统设计中应当分别运用 ArrayList 和 HashMap 代替。 数组的性能比 Vector 和 ArrayList 高，假如元素个数不变，尽量运用数组。 在运用集合类时，变量的定义以及参数的接收应当运用接口，而非详细实现类。 3.8.5 对象 创建与 释放 禁止在循环中频繁构建和释放对象；不再运用的对象应当刚好销毁；如无必要，不要序列化对象。对于频繁运用的对象，可将其缓存起来，下次运用时干脆从缓存中获得对象。 3.8.6 代码 同步 在不须要同步操作时禁止运用同步操作；尽量少用同步方法，避开运用太多的 synchronized 关键字

34、。 确需运用同步时，尽量将同步代码的范围最小化。 4 WEB 开发 规范 本部分着重 B/S 系统开发中的 JSP 编写规范。 4.1 书目 规范 4.1.1 一般原则 Web 程序要根据肯定的书目存放。公司建立积累 Web 基础库，目前主要指 Javascript和 CSS，今后随发展积累进一步提取，以促进公司开发应用的成熟度。 从 Web 应当用的根书目算起，应当用书目不应超过三层。 书目名称建议也采纳 Java 命名规范。 4.1.2 根书目 J2EE 平台上，包含/WEB-INF书目的书目称作根书目。 应用本身的基础性文件必需位于 Web 根书目下。 与详细业务相关的页面不能干脆位于根

35、书目下，必需位于根书目下相应模块的子书目下。 4.1.3 公用资源书目 Web 基础库作为公用资源，供每套应用运用。在 Web 根书目下建立/jscript 书目和/ css 书目，分别存放 Javascript 函数库和样式表文件。 除此之外，图片文件也作公用资源看待。在根书目下建立/images 书目，其下干脆存放整套应用须要运用的图片资源文件。在/images 书目下以模块名建立子书目，用于存放每个模块须要用到的图片文件。其他书目不应当再存在图片文件。（每个模块书目下也可再建images 书目用于存放模块相关的图片文件） 4.1.4 业务模块书目 根书目下以业务模块名称建立子书目，用于存

36、放各自的文件。如一个模块过大或有部分独立功能，可在其下再建立一层子书目。 4.1.5 文件引用 规范 由于常采纳 servlet 的 forward 的形式进行恳求的转发，文件之间以相对书目的形式引用经常出错。为此规定，在 Web 应用中，任何文件的应用都应当采纳肯定书目。 我司开发的应用，目前文件间的引用都是采纳的肯定书目。 但目前我司开发的应用还存在一个缺陷，当 Web 应用配置的虚拟书目不为空时，文件间的应用会出错，即找不到引用的资源。此处规定，在今后的 Web 开发中，在根书目/前加上虚拟书目，在 JSP 中以 request.getContextPath获得。示例如下： <im

37、g src=<%=request.getContextPath%>/images/news/Styleb1_1.gif> 4.1.6 配置文件书目 配置文件可以提高敏捷性，以适应相应的改变。位于/WEB-INF/书目下的 web.xml 是符合 J2EE 规范的标准配置文件，任何符合 J2EE 规范的应用服务器必需能正确解析该文件。其他配置文件也应当由该配置文件引导加载。 最好的应用是在 web.xml 文件中只指定一个加载入口，而不应当加入其他的详细配置。 经营分析系统中各子系统或模块运用的配置文件应当是独立分开的，即每个子系统或模块都有自己的配置文件。在和 BIPlatf

38、orm 集成时，通过在 web.xml中增加各子系统或模块的配置文件把子系统或模块和 BIPlatform 集成在一起。 例如， l spring 配置文件的集成： <context-param> <param-name>contextConfigLocation</param-name> <param-value> classpath:/config/common/application-common-configure.xml classpath:/config/<模块英文名>/application-<模块英文 名>

39、-configure.xml </param-value> </context-param> l Struts 配置文件的集成： <servlet> <servlet-name>aiaction</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> <init-param> <param-name>config/<模块英文名></param-name>

40、; <param-value>/WEB-INF/classes/config/<模块英文名>/struts-<模块英文名>-config.xml</param-value> </init-param> <init-param> <param-name>config/common</param-name> <param-value>/WEB-INF/ classes/config/common/struts- common-config.xml</param-value> &l

41、t;/init-param> <load-on-startup>2</load-on-startup> </servlet> 各子系统或模块中基于第三方组件/引擎的配置文件（如 Struts,Spring 配置文件）、自己读取运用的配置文件发布后都统一存放在 WEB-INF/classes/config/<modulename>/书目下； 公 用 的 配 置 文 件 （ 如 ： log4j ， ehcache 等 ） 的 配 置 文 件 存 放 在WEB-INF/classes/config/common/书目下； 表 4.1：Web 应用

42、书目结构示例 书目名称 用途 备注 /css/ 存放全部 CSS 文件 存放公共的 css 文件 /jscript/ 存放全部公用 JS 文件 存放公共的 js 文件 /images/ 存放公用图片文件 /images/<moduleName>/ 存放特定模块运用到的专用图片文件 假如特定模块没有专用图片文件，则不需创建对应书目。 /<moduleName>/ 存放各模块 JSP 文件 每个应用建立单独的书目，假如应用模块较大，可在下建立各种资源子书目（css,js,images 等） /WEB-INF/conf/ 存放遗留配置文件 如 XXX.properties, holiday.properties, mm7config.xml, smgpc.ini /WEB-INF/tlds 存放经营分析系统各模块/子系统自建的页面标签文件 Struts 或 JSF 的页面标签文 件 可 以 仍 然 存 放 在/WEB-INF 书目下