J2EE架构需求说明书

1架构需求说明1.1 总体架构图1.2 架构时序图1.3 架构基本需求说明该章节描述每一层都需要的考虑和注意的问题，及一些必须遵循的原则。

1.3.1命名规范需求详见pvcs上的“java命名规范.doc”1.3.2异常处理需求在任何地方出现致命异常，都要中止执行，回滚事物、并以友好的方式提示用户、将错误轨迹写入日志，允许的话，要将错误以邮件或者短信提示系统管理员。

异常处理必须遵循以下几个原则：1.不能丢弃异常既然捕获了异常，就要对它进行适当的处理。

不要捕获异常之后又把它丢弃，不予理睬。

捕获了异常却不作任何处理，可以算得上Java编程中的杀手。

如果你看到了这种丢弃（而不是抛出）异常的情况，可以百分之九十九地肯定代码存在问题（在极少数情况下，这段代码有存在的理由，但最好加上完整的注释，以免引起别人误解）。

异常总是意味着某些事情不对劲了，或者说至少发生了某些不寻常的事情，我们不应该对程序发出的求救信号保持沉默和无动于衷。

调用一下printStackTrace算不上“处理异常”。

不错，调用printStackTrace对调试程序有帮助，但程序调试阶段结束之后，printStackTrace就不应再在异常处理模块中担负主要责任了。

正确对待异常方式主要有四种：1）处理异常。

针对该异常采取一些行动，例如修正问题、提醒某个人或进行其他一些处理，要根据具体的情形确定应该采取的动作。

调用printStackTrace算不上已经“处理好了异常”。

2）重新抛出异常。

处理异常的代码在分析异常之后，认为自己不能处理它，重新抛出异常也不失为一种选择。

3）把该异常转换成另一种异常。

大多数情况下，这是指把一个低级的异常转换成应用级的异常（其含义更容易被用户了解的异常）。

4）不要捕获异常。

方法必须有throws来抛出异常。

2.必须指定具体的异常在catch语句中尽可能指定具体的异常类型，必要时使用多个catch。

不要试图处理所有可能出现的异常。

3.占用资源必须释放保证所有资源都被正确释放。

充分运用finally关键词。

finally是样好东西：不管是否出现了异常，Finally保证在try/catch/finally块结束之前，执行清理任务的代码总是有机会执行。

当然，编写finally块应当多加小心，特别是要注意在finally块之内抛出的异常，这是执行清理任务的最后机会，尽量不要再有难以处理的错误。

4.必须说明异常的详细信息在出现异常时，最好能够提供一些文字信息，例如当前正在执行的类、方法和其他状态信息，使其易于理解和阅读。

5.不能使用过于庞大的try块把大量的代码放入单个try块，然后再在catch语句中声明Exception，而不是分离各个可能出现异常的段落并分别捕获其异常。

这种做法为分析程序抛出异常的原因带来了困难，因为一大段代码中有太多的地方可能抛出Exception。

6.输出数据不完整不完整的数据是Java程序的隐形杀手。

考虑一下如果循环的中间抛出了异常，会发生什么事情。

循环的执行当然是要被打断的，其次，catch块会执行，就这些，再也没有其他动作了。

已经输出的数据怎么办？使用这些数据的人或设备将收到一份不完整的（因而也是错误的）数据，却得不到任何有关这份数据是否完整的提示。

对于有些系统来说，数据不完整可能比系统停止运行带来更大的损失。

较为理想的处置办法是向输出设备写一些信息，声明数据的不完整性；另一种可能有效的办法是，先缓冲要输出的数据，准备好全部数据之后再一次性输出。

1.3.3日志管理需求日志管理模块可以产生便于最终用户、系统管理员、故障维护工程师以及软件开发团队进行分析的事件记录，它为软件的开发调试和维护提供便利的手段。

它能捕获操作系统平台和执行程序的安全故障、配置错误、执行瓶颈和（或）Bug等数据信息，以纯文本、XML或程序员自定的某种方式将其格式化成日志记录，然后传递给内存、系统输出流、控制台、文件、Sockets等多种系统资源进行缓存和输出。

日志管理必须遵循几个原则：1)级别输出日志，定义一组标准的记录级别，可用于控制记录的输出。

可以把程序配置为只输出某些级别的记录，而忽略其他级别的输出。

2)提供多种输出方式，包括内存、数据库、输出流、控制台、文件和套接字等。

3)避免直接使用System.out.print来输出日志。

建议：通过封装log4j来实现日志管理1.3.4权限控制所有的权限控制都必须在控制层中进行，不能只在页面中控制，这样可以避免非法用户通过URI来获取或者操作数据，导致系统的不够安全和健壮。

具体的权限控制实现必须使用权限体系提供的统一的权限控制，如下文描述。

1.3.4.1 权限控制实现判断用户是否拥有某个权限，只需要将权限的权限码作为权限体系对外API的参数来调用该API即可。

如判断用户是否拥有权限A（其权限码是Acode），只需如下判断语句：com.szhome.security.ext.SecurityExtAp i.checkPermission(request, “Acode”)；其中request为当前请求，返回true表示拥有权限，否则不拥有。

这里的权限标识码的命名非常重要，要让程序员一看便知是哪个业务类别，哪个系统、哪个模块、哪种操作。

权限码层次的表现方式如下：比如：p_hrms_employee_edit表示p（规划）业务类别hrms（人事系统）应用的employee （人员）模块的edit(编辑)操作，根据需要权限码的层次可以增加相应的层数。

应用项目组应该把应用的所有权限的权限码放在一个或几个类中，作为这些类的静态属性来维护。

注：每个权限的权限码需要权限管理员的审核和注册，才能被使用。

1.3.5数据验证包括前端的（客户端）js的验证和后端（服务器控制层端）的java验证，对数据的验证主要包括：1)数据格式（字符格式、日期格式、整型数字格式、浮点数格式等）是否正确。

2)是否要区分大小写。

3、值是否为空。

4、字符是否超长。

尽可能在前端做好所有的数据合法性验证，出现非法数据时在前端就能检查出来，并给用户友好的提示。

在后端检查出数据非法，并抛出异常提示对性能有一定的影响。

如果前端和后端都没有做数据合法性检查，在持久层因为数据非法而抛出异常，代价将会更大。

注意：对于安全较高或者在外网使用的程序，前端和后端的验证都必须做，因为前端验证很容易被绕过的,进而危机到程序的安全。

对于在内网使用的、安全性不是太高的程序可以只做前端的验证。

1.4 MVC架构层次需求说明每一层都要履行该层对应的职责，视图层不能实现控制层的功能，控制层不能实现模型层的功能等待，否则会造成各层之间的高耦合性，进而加大系统维护、移植的风险和成本。

1.4.1V层（视图层）主要包括jsp、html、图片等，没有任何业务逻辑。

一般是从request中取得相应数据。

该层主要负责：1）提供用户请求的入口。

2）客户端的数据合法性验证。

3）显示用户请求的结果。

1.4.2C层（控制层）主要包括struts的action、Servlet等，只有控制逻辑，没有任何业务逻辑。

常见的误用是在该层（例如，在Struts的Action Bean中）实现了所有的业务逻辑。

使用该层的正确方法是调用适当的业务层服务（或对象）并将结果发送到视图层（view layer）。

该层主要负责：1）权限控制，首先判断用户是否登录，然后判断用户是否有权限执行该操作，如果没有登录或者无权操作提示相应的错误信息。

2）服务器端的数据合法性验证。

3）处理请求数据的格式，将请求数据转换成相应的DTO（数据传输对象）。

4）调用业务代理，将DTO作为业务代理方法的参数来调用代理方法。

5）重定向页面，如果调用业务代理成功后，定向到指定页面；否则定向到错误显示页面。

1.4.3M层（模型层）主要包括javaBean、ejb、jms、jmail、jts、自己封装的组件等，主要可以分为两个子层：代理层、DAO层（持久层）。

1.4.3.1 代理层业务代理（Business Delegate），在Servlet和非servlet环境下都可以调用该层的方法，Business Delegate起到客户端业务抽象化的作用。

它抽象化，进而隐藏业务服务的实现。

使用Business Delegate，可以降低表示层客户端和系统的业务服务之间的耦合程度。

根据实现策略不同，Business Delegate可以在业务服务API的实现中，保护客户端不受可能的变动性影响。

这样，在业务服务API或其底层实现变化时，可以潜在地减少必须修改表示层客户端代码的次数。

该层一般没有实际的业务逻辑、只是对业务逻辑做了一次包装。

通常可以用来调用Ejb(主要是Session Bean)，或者直接调用DAO。

该层主要负责：1）封装业务逻辑，方便控制层调用。

将控制层和模型层的耦合降到最低。

2）使业务逻辑脱离Servlet环境能正常运行。

1.4.3.2 D AO层（数据访问层或持久层）该层实现主要的业务逻辑，并与持久性数据(数据库、xml文件、word或excel文档等)交互。

持久层的常用操作（如：增加、修改、查找、删除、生成列表等）可以封装在以个通用的DAO中，实际业务实现的时候只需要继承这个通用DAO就可以实现常用的业务功能。

该层主要负责：1）处理业务逻辑。

2）业务权限判断3）操作数据库或文件（如：增加、修改、查找、删除）。

4）事务处理。

DAO层必须满足以下四个标准：一、具有透明性业务对象在不知道数据源实现的具体细节情况下，可以使用数据源。

由于实现细节隐藏在数据访问层的内部，所以访问是透明的。

二、易于迁移数据访问层使应用程序很容易迁移到其他数据库实现。

业务对象不了解底层的数据实现，所以迁移仅仅涉及到修改数据访问层。

进一步地说，如果您正在部署某种工厂策略，您可以为每个底层的存储实现提供具体的工厂实现。

如果是那样的话，迁移到不同的存储实现意味着为应用程序提供一个新的工厂实现。

三、尽量减少业务对象中代码复杂性因为数据访问层管理着所有的数据访问复杂性，所以它可以简化业务对象和使用数据访问层的其他数据客户端的代码。

数据访问层，而不是业务对象，含有许多与实现相关的代码（例如SQL语句）。

这样给开发人员带来了更高的效率、更好的可维护性、提高了代码的可读性等一系列好处。

四、把所有的数据访问集中在单独的层上由于所有的数据访问操作现在都委托给数据访问层，所以您可以将这个单独的数据访问层看做能够将应用程序的其他部分与数据访问实现相互隔离的层。

这种集中化可以使应用程序易于维护和管理。

注意：这些标准都不能明确地调出对O/R（对象到关系）映射层的需求。

O/R映射层一般用O/R映射工具创建，它提供对象对关系数据结构的查看和感知（look-and-feel）。