基于MVC模式的电子商务网站的分析及其设计应用.doc

Based on MVC Pattern Analysis and design of e-commerce (B2C)sites
Before we start our journey into the internals of Spring MVC, we first need to understand the different layers of a web application. And we’ll begin that discussion with a brief introduction of the MVC pattern in general, including what it is and why should we use it. After reviewing the MVC Pattern, we will go through the different layers in a web application and see what role each layer plays in the application.
The Model View Controller pattern (MVC pattern) was first described by Trygve Reenskaug when he was working on Smalltalk at Xerox. At that time, the pattern was aimed at desktop applications. This pattern divides the presentation layer into different kinds of components. Each component has its own responsibilities. The view uses the model to render itself. Based on a user action, the view triggers the controller, which in turn updates the model. The model then notifies the view to (re)render itself.
The MVC pattern is all about separation of concerns. As we mentioned previously, each component has its own role (see Table 3-1).

Separation of concerns is important in the presentation layer because it helps us keep the different components clean. This way, we don’t burden the actual view with business logic, navigation logic, and model data. Following this approach keeps everything nicely separated, which makes it easier to maintain and test our application.
What Is MVC：
MVC is a design pattern that breaks an application into three parts: the data (Model),
the presentation layer (View), and the user interaction layer (Controller). In other
words, the event flow goes like this:
1. The user interacts with the application.
2. The controller’s event handlers trigger.
3. The controller requests data from the model, giving it to the view.
4. The view presents the data to the user.
Or, to give a real example, Figure 1-1 shows how sending a new chat message would
work with Holla.

Figure 1-1. Sending a new chat message from Holla
1. The user submits a new chat message.
2. The controller’s event handlers trigger.
3. The controller creates a new Chat Model record.
4. The controller then updates the view.
5. The user sees his new chat message in chat log.
The MVC architectural pattern can even be implemented without libraries or frameworks.
The key is to divide up the responsibilities of the MVC components into clearly
defined sections of code, keeping them decoupled. This allows for independent development,testing, and maintenance of each component.
Let’s explore the components of MVC in detail.
The Model：
The model is where all the application’s data objects are stored. For example, we might have a User Model that contains a list of users, their attributes, and any logic associated specifically with that model.
A model does not know anything about views or controllers. The only thing a model should contain is data and the logic associated directly with that data. Any event handling code, view templates, or logic not specific to that model should be kept well clear of it. You know an application’s MVC architecture is violated when you start seeing view code in the models. Models should be completely decoupled from the rest of your application.
When controllers fetch data from servers or create new records, they wrap them in model instances. This means that our data is object oriented, and any functions or logic defined on the model can be called directly on the data.
So, rather than this:
var user = users["foo"];
destroyUser(user);
We can do something like this:
var user = User.find("foo");
user.destroy();
The first example is not namespaced or object oriented. If we have another destroyUser() function defined in our application, the two will conflict. Global variables and functions should always be kept to an absolute minimum. In the second example, the destroy() function is namespaced behind User instances, as are all the stored records.
This is ideal, since we’re keeping global variables to a minimum, exposing fewer areas to potential conflicts. The code is cleaner and can take advantage of inheritance so functions like destroy() don’t have be defined separately on every model.
Models are explored in much more depth in Chapter 3, which covers topics such as
loading in data from servers and creating object-relational mappers (ORMs).
The View：
The view layer is what’s presented to the user and is what she interacts with. In a JavaScript application, the view would be made up mostly of HTML, CSS, and Java-Script templates. Apart from simple conditional statements in templates, the views Should not contain any logic.
In fact, like models, views should also be decoupled from the rest of the application.
Views should not know anything about controllers and models—they should be independent.
Mixing up views with logic is one of the surest paths to disaster.
That is not to say MVC does not allow for presentational logic—as long as it’s not defined inside views. Presentational logic resides in what are called helpers: scripts solely for small utility functions related to the view.
The example below, which includes logic inside views, is something you should not do:
// template.html
<div>
<script>
function formatDate(date) {
/* ... */
};
</script>
${ formatDate(this.date) }
</div>
In the code above, we’re inserting the formatDate() function directly into the view,
which violates MVC, resulting in an unmaintainable mess of tag soup. By separating out presentational logic into helpers, as with the example below, we’re avoiding that problem and keeping our application’s structure MVC-compliant.
// helper.js
var helper = {};
helper.formatDate = function(){ /* ... */ };
// template.html
<div>
${ helper.formatDate(this.date) }
</div>
In addition, all presentational logic is namespaced under the helper variable, preventing conflicts and keeping the code clean and extendable.
Don’t worry too much about specifics regarding views and templates—we cover them extensively in Chapter 5. The aim of this section is to familiarize you with how views relate to the MVC architectural pattern.
The Controller：
Controllers are the glue between models and views. Controllers receive events and input from views, process them (perhaps involving models), and update the views accordingly.
The controller will add event listeners to views when the page loads, such as those
detecting when forms are submitted or buttons are clicked. Then, when the user interacts with your application, the events trigger actions inside the controllers.
You don’t need any special libraries or frameworks to implement controllers; here is an example using plain old jQuery:
var Controller = {};
// Use a anonymous function to enscapulate scope
(Controller.users = function($){
var nameClick = function(){
/* ... */
};
// Attach event listeners on page load
$(function(){
$("#view .name").click(nameClick);
});
})(jQuery);
We’re creating a users Controller that is namespaced under the Controller variable.
Then, we’re using an anonymous function to encapsulate scope, preventing variable pollution of the global scope. When the page loads, we’re adding a click event listener to a view element.
As you can see, controllers don’t require a library or framework. However, to comply with MVC’s architectural requirements, they must be separated from Models and
Views. Controllers and states are covered in more detail in Chapter 4.

基于MVC模式电子商务网站(B2C)分析和设计
在我们开始进入Spring MVC神秘世界旅程之前，我们首先要了解web应用程序不一样层。简明介绍了MVC模式，我们将开始讨论这个问题，包含它是什么，为何要使用它。
简单了解MVC模式后，我们将经过Web应用程序中不一样层，具体了解每一层在应用程序中饰演什么样角色。
Trygve Reenskaug她在Smalltalk工作时首次描述了模型—视图—控制器模式（MVC模式）。当初，该模式关键应用和桌面应用程序，这个模式把表示层分成了不一样类型组件，每个组件全部有自己不一样职责。视图利用模型来表现自己，视图在用户操作基础上触发控制器并依次更新模型，然后该模型通知视图更新其本身。
MVC模式最关键就是关系独立。正如我们前面提到，每个组件有其自己作用（见下图）。

在表示层关系独立是极其关键，因为它能够帮助我们让不一样组件保持代码简练。经过这种方法，我们不需要为视图现行导航逻辑、业务逻辑和模型数据而烦恼。根据这一措施，很好地保持了各组件关系独立，这使得我们更易于对应用程序进行维护和测试工作。
MVC定义：
MVC是一个设计模式，将应用程序分为三个部分：数据模型层（模型），表现层（视图），控制层（控制器）。换个说法说就是，MVC设计模式运行机制以下：
1、用户向服务器提交请求；
2、控制器事件处理程序触发；
3、控制器从模型中调用对应视图 ；
4、将视图显示数据给用户。
或，举一个形象例子，图1-1显示了怎样将一条新聊天消息发送给Holla处理：

图1-1 从Holla发送一条新聊天信息
1、用户提交新聊天消息；
2、控制器事件处理程序触发；
3、控制器创建一个新聊天模型统计；
4、然后，控制器更新视图；
5、在聊天统计中，用户能够看到她新聊天消息。
MVC框架模式甚至能够实现无库或无框架模式。关键是要利用代码段明确定义独立MVC组件职责，保持它们独立。这就许可了每个组件独立开发，测试和维护。
下面让我们来具体探讨MVC各组件。
模型：
模型是应用程序中负责全部数据对象存放功效。比如，我们有一个用户模型，这个模型中包含了一系列用户，那么它们属性和和该模型相关任何逻辑全部会存放在这个模型中。
模型和视图或控制器里数据没有任何关系。我们唯一知道是一个模型应包含和该数据直接相关数据和逻辑。不管是事件处理代码、视图模板、或逻辑，只要不是特定于该模型逻辑全部应该保持很明确独立关系。你要明白假如你在视图界面看到了模型中代码那就证实这个应用程序已经违反了MVC框架定义了。模型应该完全从你应用程序其它部分中独立出来。
当控制器从服务器获取数据或创建新纪录时，她们是包装在模型实例中，这意味着，我们数据是面向对象，能够直接调用数据和模型上定义任何功效或逻辑。
也就是说，不是像下面这么：
var user = users["foo"];
destroyUser(user);
我们应该像下面这么操作：
var user = User.find("foo");
user.destroy();
第一个例子中实体不是命名空间或面向对象，假如我们在我们应用程序中定义了另一个destroyUser() 函数，那么二者将发生冲突。全局变量和函数应一直保持在绝对最小。在第二个例子中，destroy（）函数命名空间在user实例以后，相当于包含了user实例里存放全部统计。
这也是一个处理方法，因为我们全局变量一直保持最小，降低了暴露潜在冲突。这么话代码就更为简练而且能够继承，正如destroy（）方法并不需要在每一个模型里分别定义。
在第3章节中我们会对模型进行更为深入探讨，其中包含从服务器数据加载和创建对象关系映射等。
视图：
视图层是展现给用户看到画面。在JavaScript应用程序中，视图大部是由HTML，CSS和JavaScript模版组成。除了模版中简单条件语句，视图层中不应该包含任何逻辑。
实际上，比如模型，视图应该也能够从应用程序其它部分独立出来。视图应该和控制器和模型没有任何关系，它们应该是完全独立。
将视图和逻辑混杂在一起必将使应用程序走向瓦解。
这并不是说MVC不许可有表象逻辑，只要它没有定义在视图中，而是驻留在所谓辅助变量中：专为部分小功效准备视图脚本。
下面例子，其中包含视图内部逻辑，这是你不应该做事情：
// template.html
<div>
<script>
function formatDate(date) {
/* ... */
};
</script>
${ formatDate(this.date) }
</div>
在上面代码中，我们将formatDate（）函数直接放到视图中，这违反了MVC规则，造成难以维护多种杂乱标签组。经过将表象逻辑独立成辅助变量，以下面例子中，我们能够避免这一问题，而且保持我们应用程序结构和MVC兼容。
// helper.js
var helper = {};
helper.formatDate = function(){ /* ... */ };
// template.html
<div>
${ helper.formatDate(this.date) }
</div>
另外，全部表象逻辑命名在辅助变量之下，这么能够预防代码之间冲突而且保持代码简练性和可扩展性。
我们不需要过分担心相关视图和模板细节，在第5章中我们会具体讲解。本节目标是让您熟悉视图怎样和MVC框模式联络起来。
控制器：
控制器是模型和视图之间桥梁。控制器从浏览器用户端收到请求，处理请求并反馈到视图中（可能包含模型），并对应地更新视图。
当页面被加载时，假如检测到表单提交或点击按钮，控制器会将事件侦听器添加到视图中，然后，当用户和应用程序交互时，事件触发会控制器里中做出回应。
你不需要任何特殊库或框架来实现控制器，这里是一个简单jQuery应用例子：
var Controller = {};
// Use a anonymous function to enscapulate scope
(Controller.users = function($){
var nameClick = function(){
/* ... */
};
// Attach event listeners on page load
$(function(){
$("#view .name").click(nameClick);
});
})(jQuery);
我们创建了一个用户控制器命名空间下控制器变量，然后，我们在封装范围内使用了一个匿名函数，预防变量在整个系统范围内蔓延。当页面加载时，我们为一个视图元素添加了一个click事件侦听器。
正如您能够看到，控制器不需要库或框架。不过为了遵从MVC框架要求，她们必需从模型和视图中分隔出来。控制器具体信息在第4章中。