关于mvc模式的电子商务网站(b2c)的分析和设计

1、based on mvc pattern analysis and designof e-commerce (b2c)sitesbefore we start our journey into the internals of spring mvc, we first need to understand the different layers of a web application. and wetl begin that discussion with a brief introduction of the mvc pattern in general, including what

2、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

3、 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, whi

4、ch 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

5、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 a

6、n 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 event handlers trigge匚3. the controller requests data from the model,

7、 giving it to the view.4. the view presents the data to the use匚or, to give a real example, figure 1-1 shows how sending a new chat message wouldwork with holla.holla彖(!)profileactivitysettingshello there!sharefigure 1-1. sending a new chat message from holla1. the user submits a new chat message.2.

8、 the controller event handlers trigger.3 the controller creates a new chat model record4. 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 responsib

9、ilities of the mvc components into clearly defined sections of code, keeping them decoupled. this allows for independent development,testing, and maintenance of each component.lets explore the components of mvc in detail.the model:the model is where all the application's data objects are stored-

10、 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. a

11、ny event handling code, view templates, or logic not specific to that model should be kept well clear of it. you know an application 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 fe

12、tch 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 = usersnfoon|;destroyuser(user);we can do something like this:

13、var user = use r.find(”foo");use 匚 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, th

14、e destroyo function is namespaced behind user instances, as are all the stored records.this is ideal, since were 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 destroyo dortt have be defi

15、ned separately on every model.models are explored in much more depth in chapter 3, which covers topics such asloading in data from servers and creating object-relational mappers (orms).the view：the view layer is whats presented to the user and is what she interacts with. in a javascript application,

16、 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 controll

17、ers 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 u

18、tility functions related to the viewthe 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, we5re inserting the formatdate() function

19、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, we9re avoiding that problem and keeping our application structure mvc-compliant./ helper.jsvar helper = ;helper.formatdate = fun

20、ction() /* . */ ;/ 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 extendabledorf t worry too much about specifics regarding views and templates一we co

21、ver 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 upda

22、te the views accordingly.the controller will add event listeners to views when the page loads, such as thosedetecting when forms are submitted or buttons are clicked. then, when the user interacts with your application, the events trigger actions inside the controllers.you dorft need any special lib

23、raries or frameworks to implement controllers; here is an example using plain old jquery:var controller = ;/ use a anonymous function to enscapulate scope(controlle 匚 users = function($)var nameclick = function();/ attach event listeners on page load$(function()$(n#view .namen).click(nameclick););)(

24、jquery);were 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, were adding a click event listener to a view element.as you can see, control

25、lers dorf t require a library or framework. however, to comply with mvc，s architectural requirements, they must be separated from models andviews. controllers and states are covered in more detail in chapter 4.基于mvc模式的电子商务网站（b2c）的分析与设计在我们开始进入spring mvc的神秘世界的旅程之前，我们首先要了解web应 用程序的不同层。简要介绍了mvc模式，我们将开始讨

26、论这个问题，包括它是什 么，为什么要使用它。简单了解mvc模式后，我们将通过web应用程序中的不同层，详细了解每一层在应 用程序中扮演什么样的角色。trygve reenskaug他在smalltalk工作时首次描述了模型一视图一控制器模 式（mvc模式）。当时，该模式主要应用与桌面应用程序，这个模式把表示层分成 了不同类型的组件，每个组件都有自己不同的职责。视图利用模型来表现自己， 视图在用户操作的基础上触发控制器并依次更新模型，然后该模型通知视图更新 其本身。mvc模式最关键的就是关系的独立。正如我们前而提到的，每个组件有其自 己的作用（见下图）。在表示层关系的独立是极其重要的，因为它可以

27、帮助我们让不同的组件保持 代码的简洁。通过这种方式，我们不需要为视图现行的导航逻辑、业务逻辑和模 型数据而烦恼。按照这一办法，很好地保持了各组件关系的独立，这使得我们更 易于对应用程序进行维护和测试工作。mvc的定义：mvc是一个设计模式，将应用程序分为三个部分：数据模型层（模型），表现 层（视图），控制层（控制器）。换个说法说就是，mvc设计模式的运行机制如下:1、用户向服务器提交请求；2、控制器的事件处理程序触发；3、控制器从模型小调用相应的视图；4、将视图显示数据给用户。或者，举一个形象的例了，图1-1显示了如何将一条新的聊犬消息发送给holla处理:holla» (!)pro

28、fileactivitysettingshello there!share图1-1从holla发送一条新的聊天信息1、用户提交新的聊天消息；2、控制器的事件处理程序触发；3、控制器创建一个新的聊天模型记录；4、然后，控制器更新视图；5、在聊天记录屮，用户可以看到他新的聊天消息。mvc框架模式其至可以实现无库或无框架模式。关键是要利用代码段明确定 义独立的mvc组件的职责，保持它们独立。这就允许了每个组件的独立开发，测 试和维护。下面让我们来详细探讨的mvc的各组件。模型：模型是应用程序中负责所冇数据对象的存储功能。例如，我们冇一个用户模 型，这个模型中包含了一系列的用户，那么它们的屈性以及与该

29、模型相关的任何 逻辑都会存储在这个模型小。模型和视图或控制器里的数据没有任何关系。我们唯一知道的是一个模型应 包含与该数据直接相关的数据和逻辑。无论是事件处理代码、视图模板、或逻辑, 只要不是特定于该模型的逻辑都应该保持非常明确的独立关系。你要明白如果你 在视图界面看到了模型屮的代码那就证明这个应用程序已经违反了 mvc框架的 定义了。模型应该完全从你的应用程序的其它部分中独立出來。当控制器从服务器获取数据或创建新的纪录时，他们是包装在模型实例中 的，这意味着，我们的数据是面向对象的，可以直接调用的数据和模型上定义的 任何功能或逻辑。也就是说，不是像下面这样：var user = usersf

30、oo;destroyuser (user);我们应该像卜面这样操作：var user = user .fin d("foo)；user. destroy ();第一个例子屮的实体不是命名空间或而向对象，如果我们在我们的应用程序 中定义了另一个destroyuser ()函数，那么两者将发生冲突。全局变量和函数 应始终保持在绝对最小。在第二个例了中，destroy ()函数的命名空间在user 实例之后，相当于包含了 user实例里存储的所有记录。这也是一种解决的方法，因为我们的全局变量始终保持最小，减少了暴露的 潜在冲突。这样的话代码就更为简洁并且可以继承，正如destroy ()方

31、法并不 需要在每一个模型里分别定义。在第3章节屮我们会对模型进行更为深入的探讨，其屮包括从服务器的数据 加载和创建对象关系映射等。视图：视图层是呈现给用户看到的画面。在javascript应用程序屮，视图大部是 由html, css和javascript模版组成。除了模版中简单的条件语句，视图层中 不应该包含任何逻辑。事实上，比如模型，视图应该也町以从应用程序的其它部分独立出来。视图 应该和控制器和模型没有任何关系，它们应该是完全独立的。将视图和逻辑混朵在一起必将使应用程序走向崩溃。这并不是说mvc不允许有表彖的逻辑，只要它没有定义在视图中，而是驻留 在所谓的辅助变量中：专为一些小功能准备的视图脚本。下面的例子，其屮包括视图内部的逻辑，这是你不应该做的事情：/ template, html<di v&g