（转帖）Wiring Your Web Application with Open Source Java(1)

One thought on “（转帖）Wiring Your Web Application with Open Source Java(1)”

1. (为预防误操作，特此备份。因为学习日记的session设置为２０分钟如果没有动作就会清除当前用户连接信息，要求重新登录。因此，你超过２０分钟没有保存的东西就有可能丢失，所以写东西请２０分钟内保存一次)

   　日记标题 （转帖）Wiring Your Web Application with Open Source Java(1)  作者: guest  创建时间: 2005-12-28 20:55:32  最近更新: 2005-12-30 20:57:54  我要评论  
   
   内容

   Print
   
        Add to Project
   
    
   
     
   
   （由admin转自：http://www.onjava.com/pub/a/onjava/2004/04/07/wiringwebapps.html）
   
   ［注：这个翻译任务是从matrix的文档wiki那里看到的，我的英文水平只能勉强看懂，但是翻译它是一举三得：学技术、学英语、为网络学习作贡献，听说这篇文章在csdn上有人翻译了，可我就是没有找到，有人找到了在这里告诉一下，以免大家重复劳动。我采用从粗到精的翻译方法，先忽略细节，按我的理解粗翻一遍，然后再请大家指正，精确化细节问题。－admin ］

   Tags: java spring struts hibernate programming
   
   Bookmark with del.icio.us
   
     
   
   Wiring Your Web Application with Open Source Java
   
   by Mark Eagle
   
   04/07/2004
   
   用Java开源技术构建你的web应用

   Building non-trivial web applications with Java is no trivial task. There are many things to consider when structuring an architecture to house an application. From a high-level, developers are faced with decisions about how they are going to construct user interfaces, where the business logic will reside, and how to persist application data. Each of these three layers has their own questions to be answered. What technologies should be implemented across each layer? How can the application be designed so that it is loosely coupled and flexible to change? Does the architecture allow layers to be replaced without affecting other layers? How will the application handle container level services such as transactions?

    　　创建一个不平凡的java的web应用不是一个平凡的任务，当为构建一个应用而建造一个构架时有许多问题需要考虑。从高层来说，开发者需要面对怎样构建用户界面－那里有业务逻辑在其中、和怎样持久化应用数据。这三层每一层都有它们各自的问题需要回答。跨越每一个层次什么技术应该被使用？怎样才能把程序设计得松耦合和比较容易修改？构建中一些层的替换不会影响到其它层？应用怎样处理容器级的服务，比如事务控制？

   There are definitely a number of questions that need to be addressed when creating an architecture for your web application. Fortunately, there have been developers that have run into these reoccurring problems and built frameworks to address these issues. A good framework relieves developers from attempting to reinvent the wheel for complex problems; it is extensible for internal customization; and it has a strong user community to support it. Frameworks generally address one problem well. However, your application will have several layers that might require their own framework. Just solving your UI problem does not mean that you should couple your business logic and persistence logic into a UI component. For example, you should not have business logic with JDBC code inside of a controller. This is not the functionality that a controller was intended to provide. A UI controller should be a lightweight component that delegates calls to other application layers for services outside the UI scope. Good frameworks naturally form guidelines where code should be placed. More importantly, frameworks alleviate developers from building code such as persistence from scratch and allow them to concentrate on the application logic that is important to a client.

   　　当为你的ＷＥＢ应用创建一个构架时，有相当多的问题需要考虑。幸运的是，有开发者已经冲锋陷阵到一些重复性的东西、建立框架解决这些问题。一个好的框架可以使程序员从为一个复杂应用重复发明轮子中解放出来；它应该是内核定义为可扩展的，有一个强大的用户群支持。框架通常能够很好的解决一方面的问题。然而，你的应用有许多层都需要它们各自的框架。就如解决你的用户界面并不意味着你应该把事务逻辑和持久化逻辑掺杂进你的用户界面组件。例如，你的控制器里面就不应该有包含jdbc代码的业务逻辑在里面，这不是控制器的功能。它应该是轻量级的，代理所有来自用户界面外的请求、调用其它服务这些请求的应用层。好的框架自然形成代码应该放在哪里的线索，更重要的是，框架减轻开发者写像持久层这样的代码的伤害，使他们专注于对客户来说很重要的应用逻辑。

   This article will discuss how to combine several well-known frameworks to achieve loose coupling, how to structure your architecture, and how to enforce a consistent design across all application layers. The challenge is combining frameworks so that each layer is exposed to each other in a loosely coupled manner, regardless of the underlying technologies. This article will discuss one strategy for combining frameworks using three popular open source frameworks. For the presentation layer we will use Struts; for our business layer we will use Spring; and for our persistence layer we will use Hibernate. You should be able to substitute any one of these frameworks in your application and get the same effect. Figure 1 shows what this looks like from a high level when the frameworks are combined.
   
   　　这篇文章将怎样合并几个著名的框架去达成松耦合，怎样构建你的构架，怎样实施一个跨所有应用层的保持一致性的设计。挑战是合并这些框架使得每一层都以一种松耦合的方式暴露给彼此，而与底层的技术无关。这篇文章将讨论合并框架的策略使用３种流行的开源框架。表现层我们将使用Struts;业务层我们将使用Springt;持久层使用Hibrenate.你将能够在你的应用中替换这些框架中的任何一种而得到同样的效果。图１展示了当这些框架被合并时从高层看是什么样子。

   Figure 1. Overview of framework architecture with Struts, Spring, and Hibernate.
   
   图１用Struts, Spring, 和 Hibernate框架构建的概览

   Application Layering
   
   Most non-trivial web applications can be divided into at least four layers of responsibility. These layers are the presentation, persistence, business, and domain model layers. Each layer has a distinct responsibility in the application and should not mix functionality with other layers. Each application layer should be isolated from other layers but allow an interface for communication between them. Let's start by inspecting each of these layers and discuss what these layers should provide and what they should not provide.
   
   应用的分层
   
   大多数不平凡的web就用能被分成至少４个各负其责的层次。这些层次是：表现层、持久层、业务层、领域模型层。每层在就用中有分别的责任，不会和其它层混淆功能。每一应用层应该彼此独立但是在它们之间允许一个接口互相交流。让我们开始深入每一层和讨论这些层应该提供什么和不应该提供什么。

   The Presentation Layer
   
   表现层
   
   ［下面是卖书的广告］
   
   Related Reading

    
   
   Hibernate: A Developer's Notebook
   
   By James Elliott

   Table of Contents
   
   Index
   
   Sample Chapter

   Read Online--Safari Search this book on Safari:
   
        
   
    Only This Book All of Safari
   
   Code Fragments only
   
   ［/广告结束］
   
     
   
   At one end of a typical web application is the presentation layer. Many Java developers understand what Struts provides. However, too often, coupled code such as business logic is placed into an org.apache.struts.Action. So, let's agree on what a framework like Struts should provide. Here is what Struts is responsible for:
   
   　　在一个典型的web应用的一端是表现层。许多java程序员懂得Struts提供什么。然而，太多的人把像业务逻辑之类的耦合的代码放进了一个org.apache.struts.Action。所以，让我们在像Struts这样一个框架应该提供什么上取得一致意见。这儿是Struts负责的：

   Managing requests and responses for a user.
   
   Providing a controller to delegate calls to business logic and other upstream processes.
   
   Handling exceptions from other tiers that throw exceptions to a Struts Action.
   
   Assembling a model that can be presented in a view.
   
   Performing UI validation.

   为用户管理请求和回应；
   
   提供一个控制器代理业务逻辑调用和其它上游的处理；
   
   处理从其它层掷出给一个Struts Action的异常；
   
   装配一个能被呈现进一个视图的模型；
   
   执行用户界面验证。

   Here are some items that are often coded using Struts but should not be associated with the presentation layer:

   Direct communication with the database, such as JDBC calls.
   
   Business logic and validation related to your application.
   
   Transaction management.
   
   Introducing this type of code in the presentation layer leads to type coupling and cumbersome maintenance.

   这儿是一些经常被使用Struts编写的而不应该和表现层相伴的项目：
   
   直接和数据库沟通，比如JDBC调用；
   
   业务逻辑和与你的应用相关的验证；
   
   传输管理；在表现层中引入这种代码将导致类型耦合和讨厌的维护。

   The Persistence Layer
   
   At the other end of a typical web application is the persistence layer. This is usually where things get out of control fast. Developers underestimate the challenges in building their own persistence frameworks. A custom, in-house persistence layer not only requires a great amount of development time, but also often lacks functionality and becomes unmanageable. There are several open source object-to-relational mapping (ORM) frameworks that solve much of this problem. In particular, the Hibernate framework allows object-to-relational persistence and query service for Java. Hibernate has a medium learning curve for Java developers who are already familiar with SQL and the JDBC API. Hibernate persistent objects are based on plain-old Java objects and Java collections. Furthermore, using Hibernate does not interfere with your IDE. The following list contains the type of code that you would write inside a persistence framework:

   持久层
   
   在典型web应用的另一端是持久层。这通常是使事情很容易失控的地方。开发者低估了建造他们自己的持久层框架的挑战性。机构内部自己写的持久层不仅需要大量的开发时间，而且缺少功能和变得难以控制。有几个开源的“对象－关系映射”（ＯＲＭ）框架非常解决问题。尤其是，Hibernate框架允许“对象－关系持久化”和Java查询服务。Hibernate对那些已经熟悉了SQL和JDBC API的Java开发者有一个适中的学习曲线。Hibernate持久对象是基于简单的老的Java对象和Java集合。此外，使用Hibernate不会被你的IDE干扰。下面的列表包含了将写在一个持久层框架里的代码类型：
   
   [注：由admin翻译上述部分２００５年１２月２８日２２：４０分；由***在***修改了上述部分;由***在***修改了上述部分...请自行填写，以便联系]
   
   Querying relational information into objects. Hibernate does this through an OO query language called HQL, or by using an expressive criteria API. HQL is very similar to SQL except you use objects instead of tables and fields instead of columns. There are some new specific HQL language elements to learn; however, they are easy to understand and well documented. HQL is a natural language to use for querying objects that require a small learning curve.

   查询相关的信息成为对象。Hibernate通过一种叫作HQL的面向对象的查询语言或者使用条件表达式API来做这个事情。HQL除了使用对象代替表、使用字段代替列外和SQL非常相似。有一些新的特殊的HQL语言元素要学；但是，它们非常容易理解和良好的文档化。HQL是一种使用来查询对象的自然语言，需要很小型的学习曲线。

   Saving, updating, and deleting information stored in a database.

   保存、更新、删除储存在数据库中的信息。

   Advanced object-to-relational mapping frameworks like Hibernate have support for most major SQL databases, and they support parent/child relationships, transactions, inheritance, and polymorphism.

   像Hibernate这样的高级“对象－关系”映射框架提供对大多数主流SQL数据库的支持，它们支持“父/子”关系、事务、继承和多态。
   
   Here are some items that should be avoided in the persistence layer:

   这儿是一些应该在持久里被避免的项目：

   Business logic should be in a higher layer of your application. Only data access operations should be permitted.

   业务逻辑应该在你的应用的一个高一些的层次里。持久层里仅仅允许数据存取操作。

   You should not have persistence logic coupled with your presentation logic. Avoid logic in presentation components such as JSPs or servlet-based classes that communicate with data access directly. By isolating persistence logic into its own layer, the application becomes flexible to change without affecting code in other layers. For example, Hibernate could be replaced with another persistence framework or API without modification to the code in any other layer.

   你不应该有持久层逻辑和你的表现层逻辑搅在一起。避免像JSPs或基于servlet的类这些在表现层里的逻辑和数据访问直接交流。靠把持久层逻辑隔离进它自己的层，应用变得易于修改而不会影响在其它层的代码。例如：Hebernate能够被其它持久层框架或者API代替而不会修改在其它任何层的代码。

   The Business Layer
   
   The middle component of a typical web application is the business or service layer. This service layer is often the most ignored layer from a coding perspective. It is not uncommon to find this type of code scattered around in the UI layer or in the persistence layer. This is not the correct place because it leads to tightly coupled applications and code that can be hard to maintain over time. Fortunately, several frameworks exist that address these issues. Two of the most popular frameworks in this space are Spring and PicoContainer. These are referred to as microcontainers that have a very small footprint and determine how you wire your objects together. Both of these frameworks work on a simple concept of dependency injection (also known as inversion of control). This article will focus on Spring's use of setter injection through bean properties for named configuration parameters. Spring also allows a sophisticated form of constructor injection as an alternative to setter injection as well. The objects are wired together by a simple XML file that contains references to objects such as the transaction management handler, object factories, service objects that contain business logic, and data access objects (DAO).

   [注：糟糕，还没有接触过Spring和PicoContainer，这下面的翻译肯定是漏洞百出，还望大虾不吝赐教：）]
   
   业务层
   
   在一个典型的web应用的中间的组件是业务层或服务层。这个服务层从编码的角度是经常最容易被忽略的层。不难在用户界面层或者持久层里找到散布在其中的这种类型的代码。这不是正确的地方，因为这导致了紧耦合的应用和代码，有时难以维护。幸运的是，几个存在的框架征对这些问题。在这个领域两个最流行的框架是Spring和PicoContainer.这些叫作微容器，你可以不费力不费神的把你的对象连在一起。所有这些框架都工作在一个简单的叫作“依赖注入”（也通称“控制反转”）的概念上。这篇文章将着眼于Spring的为指定的配置参数通过bean属性的setter注入的使用。Spring也允许一个构建器注入的复杂形式作为setter注入的一个替代。对象们被一个简单的XML文件连在一起，这个XML文件包含到像事务管理器、对象工厂、包含业务逻辑的服务对象、和数据存取对象（DAO）这些对象的引用。
   
   The way Spring uses these concepts will be made clearer with examples later in this article. The business layer should be responsible for the following:

   Handling application business logic and business validation
   
   Managing transactions
   
   Allowing interfaces for interaction with other layers
   
   Managing dependencies between business level objects
   
   Adding flexibility between the presentation and the persistence layer so they do not directly communicate with each other
   
   Exposing a context to the business layer from the presentation layer to obtain business services
   
   Managing implementations from the business logic to the persistence layer

   Spring使用这些概念的方法在这本书将在后面用例子说得更清楚一些。业务层应该负责下面这些事情：
   
   处理应用业务逻辑和业务验证；
   
   管理事务；
   
   允许界面和其它层交互；
   
   管理业务层对象之间的依赖；
   
   增加在表现层和持久层之间的灵活性，使它们彼此不直接相互沟通；
   
   从表现层暴露一个上下文给业务层获得业务服务；
   
   管理从业务逻辑到持久层的实现。

   The Domain Model Layer
   
   Finally, since we are addressing non-trivial, web-based applications we need a set of objects that can move between the different layers. The domain object layer consists of objects that represent real-world business objects such as an Order, OrderLineItem, Product, and so on. This layer allows developers to stop building and maintaining unnecessary data transfer objects, or DTOs, to match their domain objects. For example, Hibernate allows you to read database information into an object graph of domain objects, so that you can present it to your UI layer in a disconnected manner. Those objects can be updated and sent back across to the persistence layer and updated within the database. Furthermore, you do not have to transform objects into DTOs, which can get lost in translation as they are moved between different application layers. This model allows Java developers to work with objects naturally in an OO fashion without additional coding.

   领域模型层
   
   最后，因为我们讨论不平凡的、基于web的应用，我们需要一组对象能在不同的层之间移动。领域对象层由那些代表真实世界业务对象，比如：一份订单、订单项、产品等等组成。这个层允许开发者停止建造和维护不必要的数据传输对象，或者DTOs,来匹配他们的领域对象。例如，Hibernate允许你把数据库信息读进领域对象的一个对象图，所以你能以一种分离的方式把它交给你的用户界面层。那些对象能被更新和送回到持久层在数据库里更新。进一步，你不必转换对象到DTOs，DTOs能在传输中迷路，因为他们在不同的应用层间移动。这种模式允许Java开发者自然地以一种面向对象的风格和对象一起工作，没有附加的编码。
   
   [注：由admin翻译上述部分２００５年１２月３０日２０：５７分；由***在***修改了上述部分;由***在***修改了上述部分...请自行填写，以便联系] 
   
   相关资源

   转自：http://www.onjava.com/pub/a/onjava/2004/04/07/wiringwebapps.html 
   

Comments are closed.