外网J2EE架构需求说明书.doc

1、J2EE 架构需求说明书1/10文档编号项目名称项目来源 信息中心深圳市规划国土房产信息中心版 本 号 1.0 生效日期外网J2EE架构需求说明修订历史版本 说明 编制 批准 批准日期1.0 初次编写1.1 2006-07-10 修改J2EE 架构需求说明书2/101 架构需求说明1.1 总体架构图V、 、 、 、 、 、 、 、 、 jsp、 html、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 request、 、 、 、 、 、 、 、C、 、 、 、 、 、 、 、 、 struts、 action、 Servlet、 、 、

2、、 、 、 、 、 、 、 、 、 V、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、M、 、 、 、 、 、 、 、 、 javaBean、 ejb、 jms、 jmail、 jts、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 delegate、 、 、 、 、 、 EJB、 、 session bean、 、 BO、 、 、 、 、 、DAO、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、View ControlModelDelegateDAO、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、BOEJBJ2E

3、E 架构需求说明书3/101.2 架构时序图对 于 业 务 逻 辑 比 较 简单 的 请 求 ， 可 以 省 去该 层 ， 将 该 层 的 工 作转 到 EJB层 中、 、 、 、 、 、 、 、 、 、 、 、 DAO、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、requestexcute (request)、 、 、 、 、 、 、 、

4、、 、 、 、 、 、 、 、 (DTO)、 、 、 、 、 、 、 、 Request、 、 、 、 、 、 、 EJB、 、 、 、 、 DTO、 、 BO、 、 、 DTO、 、 、 、 、 、 、 、 、V、 C、 、 、 、 DAO、BO、EJB、1.3 架构基本需求说明该章节描述每一层都需要的考虑和注意的问题，及一些必须遵循的原则。1.3.1 命名规范需求详见信息中心的“java 命名规范.doc”J2EE 架构需求说明书4/101.3.2 异常处理需求在任何地方出现致命异常，都要中止执行，回滚事物、并以友好的方式提示用户、将错误轨迹写入日志，允许的话，要将错误以邮件或者短信提示系

5、统管理员。异常处理必须遵循以下几个原则：1. 不能丢弃异常既然捕获了异常，就要对它进行适当的处理。不要捕获异常之后又把它丢弃，不予理睬。捕获了异常却不作任何处理，可以算得上 Java 编程中的杀手。如果你看到了这种丢弃（而不是抛出）异常的情况，可以百分之九十九地肯定代码存在问题（在极少数情况下，这段代码有存在的理由，但最好加上完整的注释，以免引起别人误解） 。异常总是意味着某些事情不对劲了，或者说至少发生了某些不寻常的事情，我们不应该对程序发出的求救信号保持沉默和无动于衷。调用一下 printStackTrace 算不上“处理异常” 。不错，调用 printStackTrace 对调试程序有帮

6、助，但程序调试阶段结束之后，printStackTrace 就不应再在异常处理模块中担负主要责任了。正确对待异常方式主要有四种：1）处理异常。针对该异常采取一些行动，例如修正问题、提醒某个人或进行其他一些处理，要根据具体的情形确定应该采取的动作。2）重新抛出异常。处理异常的代码在分析异常之后，认为自己不能处理它，重新抛出异常也不失为一种选择。3）把该异常转换成另一种异常。大多数情况下，这是指把一个低级的异常转换成应用级的异常（其含义更容易被用户了解的异常） 。4）不要捕获异常。方法必须有 throws 来抛出异常。2. 必须指定具体的异常在 catch 语句中尽可能指定具体的异常类型，必要时使

7、用多个 catch。不要试图处理所有可能出现的异常。3. 占用资源必须释放保证所有资源都被正确释放。充分运用 finally 关键词。finally 是样好东西：不管是否出现了异常，Finally 保证在 try/catch/finally 块结束之前，执行清理任务的代码总是有机会执行。当然，编写 finally 块应当多加小心，特别是要注意在 finally 块之内抛出的异常，这是执行清理任务的最后机会，尽量不要再有难以处理的错误。J2EE 架构需求说明书5/104. 必须说明异常的详细信息在出现异常时，最好能够提供一些文字信息，例如当前正在执行的类、方法和其他状态信息，使其易于理解和阅读。

8、5. 不能使用过于庞大的 try 块把大量的代码放入单个 try 块，然后再在 catch 语句中声明 Exception，而不是分离各个可能出现异常的段落并分别捕获其异常。这种做法为分析程序抛出异常的原因带来了困难，因为一大段代码中有太多的地方可能抛出 Exception。6. 输出数据不完整不完整的数据是 Java 程序的隐形杀手。考虑一下如果循环的中间抛出了异常，会发生什么事情。循环的执行当然是要被打断的，其次，catch 块会执行，就这些，再也没有其他动作了。已经输出的数据怎么办？使用这些数据的人或设备将收到一份不完整的（因而也是错误的）数据，却得不到任何有关这份数据是否完整的提示。对

9、于有些系统来说，数据不完整可能比系统停止运行带来更大的损失。 较为理想的处置办法是向输出设备写一些信息，声明数据的不完整性；另一种可能有效的办法是，先缓冲要输出的数据，准备好全部数据之后再一次性输出。1.3.3 日志管理需求日志管理模块可以产生便于最终用户、系统管理员、故障维护工程师以及软件开发团队进行分析的事件记录，它为软件的开发调试和维护提供便利的手段。它能捕获操作系统平台和执行程序的安全故障、配置错误、执行瓶颈和（或）Bug 等数据信息，以纯文本、XML 或程序员自定的某种方式将其格式化成日志记录，然后传递给内存、系统输出流、控制台、文件、Sockets 等多种系统资源进行缓存和输出。日

10、志管理必须遵循几个原则：1、级别输出日志，定义一组标准的记录级别，可用于控制记录的输出。可以把程序配置为只输出某些级别的记录，而忽略其他级别的输出。2、提供多种输出方式，包括内存、数据库、输出流、控制台、文件和套接字等。3、避免直接使用 System.out.print 来输出日志。建议：通过封装 log4j 来实现日志管理1.3.4 权限控制所有的权限控制都必须在控制层中进行，不能只在页面中控制，这样可以避免非法用户通过 URI 来获取或者操作数据，导致系统的不够安全和健壮。具体的权限控制实现必须使用权限体系提供的统一的权限控制，如下文描述。J2EE 架构需求说明书6/101.3.4.1权限

11、控制实现判断用户是否拥有某个权限，只需要将权限的权限码作为权限体系对外 API 的参数来调用该 API 即可。如判断用户是否拥有权限 A（其权限码是 Acode） ，只需如下判断语句：com.szhome.security.ext.SecurityExtApi.checkPermission(request, “Acode”)；其中 request 为当前请求，返回 true 表示拥有权限，否则不拥有。这里的权限标识码的命名非常重要，要让程序员一看便知是哪个业务类别，哪个系统、哪个模块、哪种操作。权限码层次的表现方式如下：业务类别_ 应用名_ 模块名_ （2n）级模块名_操作名比如：p_hrm

12、s_employee_edit 表示 p（规划）业务类别 hrms（人事系统）应用的employee（人员）模块的 edit(编辑)操作，根据需要权限码的层次可以增加相应的层数。应用项目组应该把应用的所有权限的权限码放在一个或几个类中，作为这些类的静态属性来维护。注：每个权限的权限码需要权限管理员的审核和注册，才能被使用。1.3.5 数据验证包括前端的（客户端）js 的验证和后端（服务器控制层端）的 java 验证，对数据的验证主要包括：1、数据格式（字符格式、日期格式、整型数格式、浮点数格式等）是否正确。2、是否要区分大小写。3、值是否为空。4、字符是否超长。尽可能在前端做好所有的数据合法性

13、验证，出现非法数据时在前端就能检查出来，并给用户友好的提示。在后端检查出数据非法，并抛出异常提示对性能有一定的影响。如果前端和后端都没有做数据合法性检查，在持久层因为数据非法而抛出异常，代价将会更大。注意：对于安全较高或者在外网使用的程序，前端和后端的验证都必须做，因为前端验证很容易被绕过的,进而危机到程序的安全。对于在内网使用的、安全性不是太高的程序可以只做前端的验证。1.4 MVC 架构层次需求说明每一层都要履行该层对应的职责，视图层不能实现控制层的功能，控制层不能实现模型层的功能等待，否则会造成各层之间的高耦合性，进而加大系统维护、移植的风险和成本。J2EE 架构需求说明书7/101.4

14、.1 V 层（视图层）主要包括 jsp、html、图片等，没有任何业务逻辑。一般是从 request 中取得相应数据显示在用户界面中。在 V 层需要定制一套统一的样式，以便于页面风格的维护。该层主要负责：1）提供用户请求的入口。2）客户端的数据合法性验证。3）显示用户请求的结果。1.4.2 C 层（控制层）主要包括 struts 的 action、Servlet 等，只有控制逻辑，没有任何业务逻辑。常见的误用是在该层（例如，在 Struts 的 Action Bean 中）实现了所有的业务逻辑。使用该层的正确方法是调用适当的代理层服务（或对象）并将结果发送到视图层（view layer） 。该

15、层主要负责：1）权限控制，首先判断用户是否登录，然后判断用户是否有权限执行该操作，如果没有登录或者无权操作提示相应的错误信息。2）服务器端的数据合法性验证。3）处理请求数据的格式，将请求数据转换成相应的 DTO（数据传输对象） 。4）调用业务代理，将 DTO 作为业务代理方法的参数来调用代理方法。5）重定向页面，如果调用业务代理成功后，定向到指定页面；否则定向到错误显示页面。1.4.3 M 层（模型层）主要包括 javaBean、ejb、jms、jmail、jts、自己封装的组件等，主要可以分为四个子层：代理层、EJB 层、BO 层、DAO 层（持久层） 。1.4.3.1代理层业务代理（Bus

16、iness Delegate） ，在 Servlet 和非 servlet 环境下都可以调用该层的方法，Business Delegate 起到客户端业务抽象化的作用。它抽象化，进而隐藏业务服务的实现。使用 Business Delegate，可以降低表示层客户端和系统的业务服务之间的耦合程度。根据实现策略不同，Business Delegate 可以在业务服务 API 的实现中，保护客户端不受可能的变动性影响。这样，在业务服务 API 或其底层实现变化时，可以潜在地减少J2EE 架构需求说明书8/10必须修改表示层客户端代码的次数。该层一般没有实际的业务逻辑、只是对业务逻辑做了一次包装。通常

17、用来调用 Ejb(主要是 Session Bean)来实现分布式应用。为了在代理层有更好的扩展性，该层最好使用接口，在不需要引入 EJB（Session）层时更会容易。只需要提供代理新的 POJO 实现。该层主要负责：1）封装业务逻辑，方便控制层调用。将控制层和模型层的耦合降到最低。2）使业务逻辑脱离 Servlet 环境能正常运行。1.4.3.2ejb 层( 主要是 Session Bean)该层采用无状态的 Session Bean 来高层次地封装业务逻辑，无状态 Session Bean 寿命周期由容器控制，Bean 的客户并不实际拥有 Bean 的直接引用，当我们部署一个 EJB 时，

18、容器会为这个 Bean 分配几个实例到组件池（component pooling）中，当客户请求一个Bean 时，J2EE 服务器将一个预先被实例化的 Bean 分配出去，在客户的一次会话里，可以只引用一次 Bean，就可以执行这个 Bean 的多个方法。如果又有客户请求同样一个Bean，容器检查池中空闲的 Bean(不在方法中或事务中，如果一个客户长时间引用一个Bean 但执行一个方法后需要等待一段时间再执行另一个方法，则这段时间也是空闲的)，如果全部的实例都已用完则会自动生成一个新的实例放到池中，并分配给请求者。当负载减少时，池会自动管理 Bean 实例的数量，将多余的实例从池中释放。该层

19、可以有简单的业务逻辑，如调用 JTA(Java Transaction API)来进行事务处理，当然事务处理也可放在 BO 层处理，需要根据实际情况而定，如果数据源是分布式的最好用JTA 来实现事务处理，否则使用 DAO 的事务实现会更方便一些。被 ejb 封装的业务逻辑能通过 RMI 的方式被远程调用，从而实现分布式应用。在业务逻辑比较简单的情况下，为了简化架构，提供生产效率，可以不需要使用 BO 层，直接把业务逻辑和事务处理写 EJB 层中，并在 EJB 层直接调用 DAO 层。如果业务逻辑的代码超过 10 行，就要考虑使用 BO 层。该层主要负责：1、 封装业务逻辑，实现事务处理。2、

20、提供可重用的服务对象。3、 提供远程调用接口, 实现分布式应用。4、 方便调用 JMS、JTS 等 j2ee 组件。J2EE 架构需求说明书9/101.4.3.3BO 层（业务层）BO（业务）层实现具体的业务逻辑，包括需求中定义的业务规则的实现、第三方应用接口的调用、判断逻辑、事务处理，但不包括数据访问逻辑，不能出现任何 SQL 语句。在业务逻辑比较简单的情况下，为了简化架构，提供生产效率，可以省去该层，将该层需要实现的功能直接放在代理层中实现。该层主要负责：1）实现需求中定义的业务规则。2）调用第三方程序。3) 事务处理。4）业务权限判断1.4.3.4DAO 层（数据访问层或持久层）该层实现

21、数据访问逻辑，与持久性数据(数据库、xml 文件、word 或 excel 文档等)交互。持久层的常用操作（如：增加、修改、查找、删除、生成列表等）可以封装在以个通用的 DAO 中，实际业务实现的时候只需要继承这个通用 DAO 就可以实现常用的业务功能。该层主要负责：1）实现数据访问逻辑，如 SQL 的拼装。2）操作数据库或文件（如：增加、修改、查找、删除） 。DAO 层必须遵循以下几个原则： 一、具有透明性 业务对象在不知道数据源实现的具体细节情况下使用 DAO。由于实现细节隐藏在数据访问层的内部，所以访问是透明的。 二、易于迁移 数据访问层使应用程序很容易迁移到其他数据库实现。业务对象不了

22、解底层的数据实现，所以迁移仅仅涉及到修改数据访问层。进一步地说，如果您正在部署某种工厂策略，您可以为每个底层的存储实现提供具体的工厂实现。如果是那样的话，迁移到不同的存储实现意味着为应用程序提供一个新的工厂实现。 三、尽量减少业务对象中代码复杂性 因为数据访问层管理着所有的数据访问复杂性，所以它可以简化业务对象和使用数据访问层的其他数据客户端的代码。数据访问层，而不是业务对象，含有许多与实现相关的代码（例如 SQL 语句） 。这样给开发人员带来了更高的效率、更好的可维护性、提高了代码的可读性等一系列好处。 J2EE 架构需求说明书10/10四、把所有的数据访问集中在单独的层上 由于所有的数据访

23、问操作现在都委托给数据访问层，所以您可以将这个单独的数据访问层看做能够将应用程序的其他部分与数据访问实现相互隔离的层。这种集中化可以使应用程序易于维护和管理。 注意：这些标准都不能明确地调出对 O/R（对象到关系）映射层的需求。O/R 映射层一般用 O/R 映射工具创建，它提供对象对关系数据结构的查看和感知（look-and-feel） 。在我看来，在项目中使用 O/R 映射与使用 EJB 类似。在大多数情况下，并不要求它。对于包含中等规模的联合以及多对多关系的关系型数据库来说，O/R 映射会变得相当复杂。由于增加 O/R 映射解决方案本身的内在复杂性，例如延迟加载（lazy loading） 、高速缓冲等，您将为您的项目带来更大的复杂性（和风险） 。