外网J2EE架构需求的说明书.docVIP

深圳市规划国土房产 信息中心文档编号项目名称项目来源信息中心版 本 号1.0生效日期 外网J2EE架构需求说明 修订历史版本说明编制批准批准日期1.0初次编写1.12006-07-10修改架构需求说明 总体架构图 架构时序图 架构基本需求说明 该章节描述每一层都需要的考虑和注意的问题，及一些必须遵循的原则。 命名规范需求 详见信息中心的“java命名规范.doc” 异常处理需求 在任何地方出现致命异常，都要中止执行，回滚事物、并以友好的方式提示用户、将错误轨迹写入日志，允许的话，要将错误以邮件或者短信提示系统管理员。异常处理必须遵循以下几个原则： 不能丢弃异常 既然捕获了异常，就要对它进行适当的处理。不要捕获异常之后又把它丢弃，不予理睬。捕获了异常却不作任何处理，可以算得上Java编程中的杀手。如果你看到了这种丢弃（而不是抛出）异常的情况，可以百分之九十九地肯定代码存在问题（在极少数情况下，这段代码有存在的理由，但最好加上完整的注释，以免引起别人误解）。 异常总是意味着某些事情不对劲了，或者说至少发生了某些不寻常的事情，我们不应该对程序发出的求救信号保持沉默和无动于衷。调用一下printStackTrace算不上“处理异常”。不错，调用printStackTrace对调试程序有帮助，但程序调试阶段结束之后，printStackTrace就不应再在异常处理模块中担负主要责任了。 正确对待异常方式主要有四种： 1）处理异常。针对该异常采取一些行动，例如修正问题、提醒某个人或进行其他一些处理，要根据具体的情形确定应该采取的动作。 2）重新抛出异常。处理异常的代码在分析异常之后，认为自己不能处理它，重新抛出异常也不失为一种选择。 3）把该异常转换成另一种异常。大多数情况下，这是指把一个低级的异常转换成应用级的异常（其含义更容易被用户了解的异常）。 4）不要捕获异常。方法必须有throws来抛出异常。 必须指定具体的异常 在catch语句中尽可能指定具体的异常类型，必要时使用多个catch。不要试图处理所有可能出现的异常。 占用资源必须释放 保证所有资源都被正确释放。充分运用finally关键词。finally是样好东西：不管是否出现了异常，Finally保证在try/catch/finally块结束之前，执行清理任务的代码总是有机会执行。 当然，编写finally块应当多加小心，特别是要注意在finally块之内抛出的异常，这是执行清理任务的最后机会，尽量不要再有难以处理的错误。 必须说明异常的详细信息 在出现异常时，最好能够提供一些文字信息，例如当前正在执行的类、方法和其他状态信息，使其易于理解和阅读。 不能使用过于庞大的try块 把大量的代码放入单个try块，然后再在catch语句中声明Exception，而不是分离各个可能出现异常的段落并分别捕获其异常。这种做法为分析程序抛出异常的原因带来了困难，因为一大段代码中有太多的地方可能抛出Exception。 输出数据不完整 不完整的数据是Java程序的隐形杀手。考虑一下如果循环的中间抛出了异常，会发生什么事情。循环的执行当然是要被打断的，其次，catch块会执行，就这些，再也没有其他动作了。已经输出的数据怎么办？使用这些数据的人或设备将收到一份不完整的（因而也是错误的）数据，却得不到任何有关这份数据是否完整的提示。对于有些系统来说，数据不完整可能比系统停止运行带来更大的损失。 较为理想的处置办法是向输出设备写一些信息，声明数据的不完整性；另一种可能有效的办法是，先缓冲要输出的数据，准备好全部数据之后再一次性输出。 日志管理需求 日志管理模块可以产生便于最终用户、系统管理员、故障维护工程师以及软件开发团队进行分析的事件记录，它为软件的开发调试和维护提供便利的手段。 它能捕获操作系统平台和执行程序的安全故障、配置错误、执行瓶颈和（或）Bug等数据信息，以纯文本、XML或程序员自定的某种方式将其格式化成日志记录，然后传递给内存、系统输出流、控制台、文件、Sockets等多种系统资源进行缓存和输出。 日志管理必须遵循几个原则： 1、级别输出日志，定义一组标准的记录级别，可用于控制记录的输出。可以把程序配置为只输出某些级别的记录，而忽略其他级别的输出。 2、提供多种输出方式，包括内存、数据库、输出流、控制台、文件和套接字等。 3、避免直接使用System.out.print来输出日志。 建议：通过封装log4j来实现日志管理 权限控制 所有的权限控制都必须在控制层中进行，不能只在页面中控制，这样可以避免非法用户通过URI来获取或者操作数据，导致系统的不够安全