多层体系结构的Web开发框架模型外文翻译资料

 2022-11-21 16:54:21

Five-layer Web Development Model Based on J2EE Architecture

Wang Zhenghong1, a, Li Xiaoping2,b

1Beijing Institute of Technology Continuing Education and Modern Distance Education College , Beijing 100081

2Beijing Institute of Technology Adult Education College , Beijing 100081

a wzhwzh@bit.edu.cn b lxpmx@x263.net

Keywords: J2EE; MVC; Struts; Hibernate; Multi-source data

Abstract. Currently ,there commonly exists some inadequacies such as Low degree of reusability、 tedious Maintenance work 、weak Program contingency etc. in Multi-tier web architecture. Therefore, it is particularly important to improve the efficiency of the development , selection of the optimal technology for stratified design and framework building, and giving full play to the application of systemrsquo;s flexibility , safety and practicality in the process of developing a Web application system. The authors explore the web development framework of J2EE-based five - layer architecture, alalysis the limitations of object persistence which is based on Struts framework in J2EE architecture, and designed a multi-source data access components between the business logic layer and persistence layer, which realized a uniform access to heterogeneous databases of different types , different structures , different environment , different usage.

Web development framework model of the multi-tier architecture

1.1 Five-layer architecture design of J2EE

1.1.1 Presentation Layer

The presentation layer consists of objects defined to accept user input and to display application outputs. Presentation technologies that can be used with J2EE include

HTML/JSP, with servlets acting as Controllers.

Applets, using Abstract Windowing Toolkit (AWT) or Swing

Applications, using AWT or Swing

We will focus on the first option, the most common for supporting thin clients and the one that uses the most J2EE technologies, but we will at times bring up issues related to the other two.

1.1.2 Controller/Mediator Layer

Whatever the presentation technology happens to be, requests for domain state and behavior are done through a Controller object defined for the particular presentation requirements. This Controller object implements the Mediator design pattern from [Gamma]. An important design requisite involves making sure that domain-specific logic is not defined in presentation object methods but rather is obtained from a Mediator-referenced domain object. Application navigation topology also is defined within this layer.

Servlets control a client request for dynamic HTML content. Servlets produce HTML by either delegating to a JSP page or simply putting raw HTML tags onto the available PrintWriter. The JSP approach naturally separates the servlet from HTML presentation logic, as JSPs are physical documents, independent of the servlet. However, for producing raw HTML tags, the developer might be tempted to accomplish this with a method defined in a servlet. A better design involves creating a separate HTML-generating class, effectively isolating this functionality .

A Servlet as a Controller

Servlets dont generate HTML but rather facilitate the production of dynamic HTML content by providing an entry point into a server-side JVM through a Web server. This entry point, known as a servlet, enables the developer to resolve session objects for individual users, access HTML form parameters, and respond with dynamically generated HTML. For a more detailed explanation of the Servlet API, refer to Chapter 4.

Application presentation objects interact with a domain model in generalized ways, regardless of the presentation technology. For instance, a GUI presents a list of choices, a collection of domain model objects; the same collection can be used to populate an HTML list. For that matter, the same collection could be used to provide a list of choices in a voice-response unit interface .

Mediators Used by Various Presentation Technologies

Mediators capture and decouple application-specific functionality from presentation technology by performing domain model requests for presentation or Controller objects that drive a specific application use case. Mediator classes are defined to satisfy a specific application user interface function or use case; therefore, they are less granular than controllers that usually exist at a component level. Mediators implement behavior that would usually end up in presentation classes as methods/scripts. Moreover, consistently applying mediator objects offers more than just loose coupling a domain model from presentation technologies. Mediators provide a convenient and consistent way to transfer application state between user interfaces, eliminating the typical highly parameterized approach. Additionally, transaction behavior finds an appropriate location in mediator objects, as constraints of navigation and units of work are tied to application-specific functionality.

Mediators also play a role supporting scalability using distributed object technologies, such as EJBs or CORBA. In the case of mediators in a GUI application, making the mediator a distributed object makes for a thin client, and Web-based applications using servlets can keep sessions lightweight by referencing distributed mediator proxies.

Distributed Mediator Topology

The key to mediators presentation independence is the enforcement of strict layering, meaning that mediators should not contain any references to presentation objects. However, mediators are free to reference domain object public state and behavior. Care must also be taken not to define domain logic in mediato

剩余内容已隐藏，支付完成后下载完整资料

基于J2EE体系结构的五层Web开发模型

Wang Zhenghong1, a, Li Xiaoping2,b

1北京理工大学继续教育与现代远程教育学院，北京100081

2北京理工大学成人教育学院，北京100081

a wzhwzh@bit.edu.cn b lxpmx@x263.net

摘要：目前，在多层Web体系结构中普遍存在一些不足之处，如重用性低，维护工作繁琐，程序不稳定等。因此，在开发Web应用系统的过程中，提高开发效率，选择最优分层设计技术和构建框架，充分发挥系统灵活性，安全性和实用性的应用性尤为重要。作者探索了基于J2EE的五层体系结构的Web开发框架，分析了J2EE架构中基于Struts框架的对象持久化的局限性，在业务逻辑层和持久层之间设计了一个多源数据访问组件，实现了对不同类型，不同结构，不同环境，不同用途的异构数据库的统一访问。

关键词：J2EE;MVC;Struts的;Hibernate的; 多源数据

1 多层体系结构的Web开发框架模型

J2EE的五层体系结构设计

1.1.1 表示层

表示层由定义为接受用户输入和显示应用程序输出的对象组成。可用于J2EE的演示技术包括HTML / JSP，servlet充当控制器。

小程序:使用抽象窗口工具包（AWT）或Swing。

应用程序:使用AWT或Swing。

1.1.2 控制器/中介层

无论呈现技术如何发生，通过为特定演示要求定义的Controller对象来完成对域状态和行为的请求。这个Controller对象从[Gamma]实现了Mediator设计模式。一个重要的设计要求涉及确保实体特定的逻辑没有在演示对象方法中定义，而是从Mediator引用的实体对象中获得。应用程序导航拓扑也在此层中定义。

Servlet控制客户端对动态HTML内容的请求。 Servlet通过委托给JSP页面或简单地将原始HTML标签放到可用的PrintWriter上来生成HTML。 JSP方法自然将servlet与HTML表示逻辑分开，因为JSP是独立于servlet的物理文档。但是，为了生成原始的HTML标签，开发人员可能会试图用servlet中定义的方法来完成此操作。更好的设计涉及创建一个单独的HTML生成类，有效隔离此功能。

一个Servlet可以作为一个控制器。Servlet不会生成HTML，而是通过通过Web服务器为服务器端JVM提供入口点来促进生成动态HTML内容。 这个入口点称为servlet，它使开发人员能够为单个用户解析会话对象，访问HTML表单参数，并使用动态生成的HTML进行响应。

无论演示技术如何，应用程序演示对象都可以通用方式与域模型进行交互。 例如，一个GUI提供了一个选择列表，一个域模型对象的集合; 可以使用相同的集合来填充HTML列表。 就此而言，可以使用相同的集合来提供语音响应单元界面中的选项列表。

各种演示技术使用的调解器。

介体通过执行演示文稿的域模型请求或驱动特定应用程序用例的Controller对象来捕获和分离演示技术中的特定于应用程序的功能。介子类定义为满足特定的应用程序用户界面功能或用例;因此，它们比通常存在于组件级别的控制器的粒度要小。介体实现的行为通常最终会在表现类中作为方法/脚本出现。此外，始终如一地应用中介对象不仅仅是将演示技术中的实体模型耦合起来。介体提供了一种方便而一致的方式来在用户界面之间传输应用程序状态，从而消除了典型的高参数化方法。此外，事务行为在中介对象中找到合适的位置，因为导航和工作单元的约束与特定于应用程序的功能相关联。

调解人也扮演支持使用分布式对象技术（如EJB或CORBA）的可伸缩性的角色。对于GUI应用程序中的调解器，将调解器作为分布式对象可用于瘦客户机，而使用servlet的基于Web的应用程序可通过引用分布式调解器代理来保持会话轻量级。

分布式调解器拓扑用来调解人介绍独立性的关键是严格分层的执行，这意味着调解人不应该包含对表示对象的任何引用。 但是，介体可以自由引用域对象的公共状态和行为。 还必须注意不要在介体中定义域逻辑。 通过问自己：“我是否仍然可以通过仅使用现有的域对象来执行或获取请求的域操作？”，从而避免这种陷阱。 如果答案是“不，我需要一个中介对象”，中介正在实施属于该域的行为。

介体实现与控制器相同的设计意图。 但是，代替松散耦合表示对象（如GUI组件），介体帮助解耦和捕获域模型的应用程序表示要求。

调解对象是特定于应用程序的，并且对他们正在代表的域进行深入的了解。 因此，他们通常会定义快速将请求委托给域的方法。 常见的介体操作涉及生成将显示在下拉选择列表中的对象向量。 实现JSP页面以显示此列表的开发人员不必编写特定于域的代码来获取此列表，而是可以简单地从中介实例获取它。 同样，将从该列表中进行选择，最终将导致将执行操作的“选定”域实例。 同样，不是在特定于演示文稿的代码（如JSP页面）中定义此特定于应用程序的行为，而是可以在介体类中定义的方法中捕获行为。

另外值得一提的是，介体设计并不特定于基于HTML / servlet的应用程序。 调解人以特定于应用程序的方式与域相关联; 但是，他们没有引用特定的应用程序技术，使其可以通过各种演示技术重用。 认为单个中介类型可以为servlet和基于GUI的应用程序“调解”是现实的。

在基于servlet的应用程序的上下文中，介体提供了一种便捷且一致的方式来存储用户特定的应用程序会话对象。 通常将多个servlet定义为支持单个基于Web的应用程序功能。 当然，Servlet API提供了一种将域对象状态与用户会话相关联的机制; 然而，该函数中可能涉及多个域对象，并且必须从会话中“获取”并“放入”多个对象，这需要额外的簿记。 有关如何使用介体来帮助进行会话管理的详细讨论。

1.1.3 实体层

实体层可能既是理解分层系统中最困难的部分，也是实现最具挑战性的部分。 为了理解域对象是什么，我们必须回到面向对象编程的基础。 当我们学习Java编程或面向对象设计时，所看到的第一个例子通常是根据具体对象来进行的。 这可能是Booch中控制系统的一个例子，其中建模的对象（如温度传感器和空调）是物理的，或者通过简单的游戏模拟物体（如扑克牌）进行建模。

不幸的是，当开始考虑他们自己的日常问题时，许多程序员反而看到更多抽象的东西，比如窗口和数据库表格，而不是书籍和教程中出现的很好的具体事物。 这很不幸，因为用软件建模业务方面可能是程序员能够解决软件开发中最棘手问题的最强大工具之一。 通过捕获对象中的业务抽象可以使系统更加灵活，并且还可以在系统中代表业务问题的各个部分之间形成一个关键区别 - 它的本质 - 以及由此产生的实现的“事故” 技术上的选择可能是短暂的。

实体对象通常作为标准的Java类来实现，它们可能会或可能不会实现或遵循JavaBeans规范。 如果实体对象以JavaBean实现，那么这些类的更高用户将拥有更多选项，以便在可视化编程工具（如VisualAge for Java）中对其进行操作。 相应地，JavaBean规范需要额外的功能，这些功能必须实现以使这些选项可用。

正如我们已经讨论过的，J2EE为实现实体对象提供了另一种选择。 程序员可以选择将实体对象实现为EJB，这在分发，事务功能和持久性方面提供了一些好处。 即使在使用EJB时，也可以使用标准Java类和EJB的混合体。

1.1.4 数据映射层

正如我们所描述的那样构建领域层的一个结果是，如果我们对领域对象采取更抽象的视图，那么不应该关注纯粹的实现细节。 例如，企业编程中最常见的问题之一就是如何从数据库中提取数据或更新数据。 除了使这种行为成为域对象的一部分之外，还需要第二组对象来执行此功能。 以这种方式分离行为具有许多好处，包括可以在不更改域实施的情况下更改实施细节（如数据库供应商或数据库模式）。

像这样的设计需要一个单独的层，通常称为映射或持久层，它可以将数据从域对象移动到后端数据源，反之亦然。 一些商业产品，如VisualAge Persistence Builder，JavaBlend和TOPLink可以添加这种行为。 但是，对于使用J2EE的程序员来说，这种行为通常会通过EJB容器提供的API来使用。 WebSphere中的EJB容器为实体EJB的数据持久性提供了一个简单而一致的接口。 但是，当我们需要在JavaBeans和EJB之间移动数据时，即使在使用EJB的设计中，我们仍然需要实现一些映射功能。 我们将在后面的章节深入讨论这个话题。

从架构设计的角度来看，映射操作如何从JavaBean领域参与，应该是厂商中立的。 应该将域模型实现为从公共基类继承的JavaBean。 此类中定义的方法允许扩展类始终发出持久性操作，以从底层“映射”数据源检索，保存和删除对象。 附录A讨论了本书案例研究中出现的Mapper设计和实现细节的讨论。

1.1.5 数据源访问层

关系数据库（如DB2，Oracle和Informix）可以说是IT组织存储和查询企业数据的最常见方式。 认识到这一深远的市场份额，Sun提供了JDBC（Java数据库连接）API，它允许生产和执行供应商中立的SQL。[1] 开发人员可以针对任何JDBC兼容的驱动程序使用标准的ANSI SQL。 特定的API和可用JDBC驱动程序的类型超出了本讨论的范围; 请参阅Sun的Java Web站点上提供的JDBC规范以获取更多信息。

这如何融入J2EE架构？ 数据源访问存在于体系结构的EJB部分中。 EJB容器代表实体对象执行映射和特定的持久操作。 容器通过使用数据源访问框架和JDBC等API来实现这一点。 像servlet和JavaBeans这样的其他对象也可以直接使用JDBC访问企业数据。

1.2 集成Struts框架和Hibernate框架来实现MVC设计模式

基于模型（Model） - 视图（View） - 控制器（MVC）模式的应用架构，Struts具有模块化，灵活性和组件重用的优点。但是，struts框架主要是为表示层设计的，而不是对后端业务逻辑层的强大支持。在项目开发过程中，存在以下限制：分工横向，工作按模块划分，软件开发成本相应较高;数据层的封装以及不同模块之间的协调和沟通需要花费大量的时间，这导致了开发时间的增加;项目移植相对较差，导致为不同的数据库编写不同的SQL语句;该项目的可扩展性相对较差，因此必须修改数据库表的结构以适应新的要求或更改，但这需要更高的人员要求来重新编写SQL语句和备份数据库并执行其他复杂的操作。由于数据库操作的开发者参差不齐，开发经验并不相同，导致系统性能可能相对较差。 Hibernate是一个开源的O / R Mapping（对象/关系映射）框架，它执行一个轻量级的对象封装，以便JDBC通过面向对象的机制来处理数据库操作。 Hiber2nate不仅管理从Java类到数据库表的映射，还提供数据查询和数据检索，可以显着减少在开发过程中使用SQL和JDBC手动处理数据的时间。作者指出，Hibernate应该被集成到J2EE架构中，并且对象持久性部分将从支撑框架分离到Hibernat e来实现。根据Struts架构，数据库操作工作由模型层来处理，因此Struts的模型层可以分为两部分，一部分负责业务逻辑，另一部分使用Hibernate实现对象持久化处理。同时隔离特定的业务逻辑来创建一个新的业务逻辑层，负责业务逻辑和持久化对象与Hibernate之间的交互。

Struts和Hibernate框架的集成实现了控制流，业务调用和表达的分离，使得系统在开发效率，可维护性，可扩展性方面有了很大的提升。 在这个模型中，客户层可以被视为V，它是浏览器向用户显示的DHTML接口; JavaBeans和Hibernate将业务逻辑层和持久层与作为系统核心部分的M进行比较。 Web层对应于C，C控制用户对业务逻辑的操作，同时控制操作结果向用户显示，由Servlet和JSP程序组成。 其中PO是通过调用模型层生成的持久对象，并通过JSP向用户显示。

1.3 集成Struts和Hibernate来实现J2EE分层架构

根据前面的分析，Struts框架和Hibernate框架的集成，构成了一个新的Web应用程序开发框架，实现了J2EE应用程序的多层体系结构。一方面框架继承了表示层中的Struts框架，其优点是提供了一个全面的标签库，并负责接收和转发页面请求以实现表示逻辑和业务逻辑的分离;另一方面它扮演着Hibernate框架在数据持久层中的特点，并通过Hibernate框架封装持久层和事务，实现业务逻辑和数据库访问的分离，从而形成一个层次清晰，更简洁，功能更全的Web框架，它可以减少各级之间的耦合，提高组件的可重用性，降低代码编辑器的复杂性，帮助开发人员专注于业务逻辑的实现，并有利于系统的可维护性。

集成了Struts和Hibernate来实现J2EE分层架构，系统采用由客户层，Web层，业务逻辑，数据持久层和数据库层组成的五层结构设计。客户层运行在用户计算机的Web浏览器上; Web层运行在Web服务器上，该服务器使用Struts框架技术来实现mang功能，比如提供对客户端请求的接收/响应，控制整个系统工作流以及通过调用Action和Business之间的交互来动态生成WEB页面逻辑层和格式化业务数据;业务逻辑层负责实现整个系统的核心业务逻辑，由JavaBeans或EJB实现;由Hibernate框架技术实现的数据持久层完成

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[22916]，资料为PDF文档或Word文档，PDF文档可免费转换为Word

原文和译文剩余内容已隐藏，您需要先支付 30元 才能查看原文和译文全部内容！立即支付

以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。

您可能感兴趣的文章