本科生毕业论文(设计)外文翻译

题 目 基于Web的精品课程网站平台设计与开发

Expert Spring MVC and Web Flow

CHAPTER 3

Spring MVC Application Architecture

Before we begin our exploration of the internals of Spring MVC, it is important to discuss how a typical Spring MVC is built. In this chapter, we will answer such questions as, “Where should the business logic live?” and “What are the correct levels of abstractions?” We will present the entire picture of a Spring MVC web application to better explain the individual roles that Spring MVC plays and where it fits in the overall architecture.

Mastering a new framework requires more than studying its APIs. Examining and understanding the architecture of a complete Spring MVC web application provides you with clues and motivations for the design of the framework itself. This allows for a higher level of understanding, allowing you to make more contextually sound choices when building your application.

Layers of Abstractions

Spring MVC applications are broken down into a series of layers. We consider a layer to be a discrete, orthogonal area of concern within an application. For instance, all of the persistence code is considered a separate layer from the view rendering code. Layers are abstractions within an application, and interfaces provide the contract by which layers interact. Some layers might be well hidden, used only by the layer immediately above it. In contrast, the most important layer (the domain model itself) spans nearly all the other layers in the system.

Layers are conceptual boundaries and are not necessarily physically isolated. More often than not, all of the layers will be located within the same virtual machine for a web application. For a good discussion on application distribution, consult Rod Johnsonrsquo;s Expert One-on-One J2EE Design and Development (Wrox, 2002).

Thinking in layers can help conceptualize the flow through an application. Visualizing the applicationrsquo;s layers as a cake (layers of cake stacked one on another) is a common and convenient way to illustrate how the application is organized. Typical metaphors such as “down into persistence” and “back up to the user interface” refer to a cake, and denote a sense of vertical direction, reinforcing the metaphor. Figure 3-1 illustrates the common, highly generalized layers for web applications.

Typically, any persistence functionality is at the bottom of the cake, while the user interface is at the top. What is found in the middle, and how it is organized, is the subject of this chapter. We will use this metaphor when explaining our architecture.

Breaking it down further, typical Spring MVC applications have at least five layers of abstraction that you as a developer will code to. The layers are

bull; user interface

bull; web

bull; service

bull; domain object model

bull; persistence

You might notice that common applications elements, such as transaction management or security, are not in the preceding list. If you are familiar with the Spring Framework and its extensive use of aspect-oriented programming (AOP), this wonrsquo;t come as a surprise. Transaction management, for instance, is considered a transparent aspect of a system, not a full layer. Figure 3-2 more specifically illustrates the relative placement of the different layers.

You will notice that the domain model vertically spans all the other layers. This is because all the other layers have a dependency on the domain model. It is the only layer that crosscuts all the rest.

Layer Isolation

Isolating problem domains, such as persistence, web navigation, and user interface, into separate layers creates a flexible and testable application. Implementations of each layer will vary independently, increasing the flexibility of the application. Decreasing the coupling between areas of the application will increase the testability, making it easier to test each part of the application in isolation.

This isolation is accomplished by minimizing the amounts of dependencies between the layers. The fewer dependencies a layer has upon itself, the less costly it is to change that layer. It is a best practice to ensure that a layer is required only by one or two other layers. Avoid having one single layer required by many different parts of the application.

You can avoid dependency explosion in at least two ways. If a layer begins to employ too many layers, consider creating a new layer of abstraction wrapping all the previous interactions. On the other hand, if you find that a layer has permeated throughout many layers, consider if that layer is itself an aspect of the system. If the functionality can be applied across great swaths of the system transparently, use Springrsquo;s AOP functionality to remove the explicit dependency from your code.

The important point to remember is that one of the great benefits of layering an application is it creates a decoupled design. When you discover a layer or facet of the application that is too intrusive, refactor it to another abstraction or through AOP. This will keep your application flexible and testable.

Java Interface As Layer Contract

The Java interface is the key enabler to building an application with layers. The interface is a contract for a layer, making it easy to keep implementations and their details hidden while enforcing correct layer usage.

The benefits of low coupling provided by interfaces have been well known for some time. Their full benefits have been hindered because the instantiation of concrete types was still required. The promise of implementati

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

本科生毕业论文(设计)外文翻译

题 目 基于Web的精品课程网站平台设计与开发

学生姓名 黄焱晶

学 号 20121308109

学 院 计算机与软件学院

专 业 计算机科学与技术

指导教师 杜杰

二Ｏ一六年五月二十日

Expert Spring MVC and Web Flow

CHAPTER 3

Spring MVC Application Architecture

Before we begin our exploration of the internals of Spring MVC, it is important to discuss how a typical Spring MVC is built. In this chapter, we will answer such questions as, “Where should the business logic live?” and “What are the correct levels of abstractions?” We will present the entire picture of a Spring MVC web application to better explain the individual roles that Spring MVC plays and where it fits in the overall architecture.

Mastering a new framework requires more than studying its APIs. Examining and understanding the architecture of a complete Spring MVC web application provides you with clues and motivations for the design of the framework itself. This allows for a higher level of understanding, allowing you to make more contextually sound choices when building your application.

Layers of Abstractions

Spring MVC applications are broken down into a series of layers. We consider a layer to be a discrete, orthogonal area of concern within an application. For instance, all of the persistence code is considered a separate layer from the view rendering code. Layers are abstractions within an application, and interfaces provide the contract by which layers interact. Some layers might be well hidden, used only by the layer immediately above it. In contrast, the most important layer (the domain model itself) spans nearly all the other layers in the system.

Layers are conceptual boundaries and are not necessarily physically isolated. More often than not, all of the layers will be located within the same virtual machine for a web application. For a good discussion on application distribution, consult Rod Johnsonrsquo;s Expert One-on-One J2EE Design and Development (Wrox, 2002).

Thinking in layers can help conceptualize the flow through an application. Visualizing the applicationrsquo;s layers as a cake (layers of cake stacked one on another) is a common and convenient way to illustrate how the application is organized. Typical metaphors such as “down into persistence” and “back up to the user interface” refer to a cake, and denote a sense of vertical direction, reinforcing the metaphor. Figure 3-1 illustrates the common, highly generalized layers for web applications.

Typically, any persistence functionality is at the bottom of the cake, while the user interface is at the top. What is found in the middle, and how it is organized, is the subject of this chapter. We will use this metaphor when explaining our architecture.

Breaking it down further, typical Spring MVC applications have at least five layers of abstraction that you as a developer will code to. The layers are

bull; user interface

bull; web

bull; service

bull; domain object model

bull; persistence

You might notice that common applications elements, such as transaction management or security, are not in the preceding list. If you are familiar with the Spring Framework and its extensive use of aspect-oriented programming (AOP), this wonrsquo;t come as a surprise. Transaction management, for instance, is considered a transparent aspect of a system, not a full layer. Figure 3-2 more specifically illustrates the relative placement of the different layers.

You will notice that the domain model vertically spans all the other layers. This is because all the other layers have a dependency on the domain model. It is the only layer that crosscuts all the rest.

Layer Isolation

Isolating problem domains, such as persistence, web navigation, and user interface, into separate layers creates a flexible and testable application. Implementations of each layer will vary independently, increasing the flexibility of the application. Decreasing the coupling between areas of the application will increase the testability, making it easier to test each part of the application in isolation.

This isolation is accomplished by minimizing the amounts of dependencies between the layers. The fewer dependencies a layer has upon itself, the less costly it is to change that layer. It is a best practice to ensure that a layer is required only by one or two other layers. Avoid having one single layer required by many different parts of the application.

You can avoid dependency explosion in at least two ways. If a layer begins to employ too many layers, consider creating a new layer of abstraction wrapping all the previous interactions. On the other hand, if you find that a layer has permeated throughout many layers, consider if that layer is itself an aspect of the system. If the functionality can be applied across great swaths of the system transparently, use Springrsquo;s AOP functionality to remove the explicit dependency from your code.

The important point to remember is that one of the great benefits of layering an application is it creates a decoupled design. When you discover a layer or facet of the application that is too intrusive, refactor it to another abstraction or through AOP. This will keep your application flexible and testable.

Java Interface As Layer Contract

The Java interface is the key enabler to building an application with layers. The interface is a contract for a layer, making it easy to keep implementations and their details hidden while enforcing correct layer usage.

The benefits of low coupling provided by interfaces have been well known for some time. Their full benefits have been hindered because the instantiation of concrete types was still required. The promise of implementati

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

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