關(guān)于mvc模式的電子商務(wù)網(wǎng)站(b2c)的分析和設(shè)計

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模式的電子商務(wù)網(wǎng)站（b2c）的分析與設(shè)計在我們開始進入spring mvc的神秘世界的旅程之前，我們首先要了解web應 用程序的不同層。簡要介紹了mvc模式，我們將開始討

26、論這個問題，包括它是什 么，為什么要使用它。簡單了解mvc模式后，我們將通過web應用程序中的不同層，詳細了解每一層在應 用程序中扮演什么樣的角色。trygve reenskaug他在smalltalk工作時首次描述了模型一視圖一控制器模 式（mvc模式）。當時，該模式主要應用與桌面應用程序，這個模式把表示層分成 了不同類型的組件，每個組件都有自己不同的職責。視圖利用模型來表現(xiàn)自己， 視圖在用戶操作的基礎(chǔ)上觸發(fā)控制器并依次更新模型，然后該模型通知視圖更新 其本身。mvc模式最關(guān)鍵的就是關(guān)系的獨立。正如我們前而提到的，每個組件有其自 己的作用（見下圖）。在表示層關(guān)系的獨立是極其重要的，因為它可以

27、幫助我們讓不同的組件保持 代碼的簡潔。通過這種方式，我們不需要為視圖現(xiàn)行的導航邏輯、業(yè)務(wù)邏輯和模 型數(shù)據(jù)而煩惱。按照這一辦法，很好地保持了各組件關(guān)系的獨立，這使得我們更 易于對應用程序進行維護和測試工作。mvc的定義：mvc是一個設(shè)計模式，將應用程序分為三個部分：數(shù)據(jù)模型層（模型），表現(xiàn) 層（視圖），控制層（控制器）。換個說法說就是，mvc設(shè)計模式的運行機制如下:1、用戶向服務(wù)器提交請求；2、控制器的事件處理程序觸發(fā)；3、控制器從模型小調(diào)用相應的視圖；4、將視圖顯示數(shù)據(jù)給用戶?；蛘撸e一個形象的例了，圖1-1顯示了如何將一條新的聊犬消息發(fā)送給holla處理:holla» (!)pro

28、fileactivitysettingshello there!share圖1-1從holla發(fā)送一條新的聊天信息1、用戶提交新的聊天消息；2、控制器的事件處理程序觸發(fā)；3、控制器創(chuàng)建一個新的聊天模型記錄；4、然后，控制器更新視圖；5、在聊天記錄屮，用戶可以看到他新的聊天消息。mvc框架模式其至可以實現(xiàn)無庫或無框架模式。關(guān)鍵是要利用代碼段明確定 義獨立的mvc組件的職責，保持它們獨立。這就允許了每個組件的獨立開發(fā)，測 試和維護。下面讓我們來詳細探討的mvc的各組件。模型：模型是應用程序中負責所冇數(shù)據(jù)對象的存儲功能。例如，我們冇一個用戶模 型，這個模型中包含了一系列的用戶，那么它們的屈性以及與該

29、模型相關(guān)的任何 邏輯都會存儲在這個模型小。模型和視圖或控制器里的數(shù)據(jù)沒有任何關(guān)系。我們唯一知道的是一個模型應 包含與該數(shù)據(jù)直接相關(guān)的數(shù)據(jù)和邏輯。無論是事件處理代碼、視圖模板、或邏輯, 只要不是特定于該模型的邏輯都應該保持非常明確的獨立關(guān)系。你要明白如果你 在視圖界面看到了模型屮的代碼那就證明這個應用程序已經(jīng)違反了 mvc框架的 定義了。模型應該完全從你的應用程序的其它部分中獨立出來。當控制器從服務(wù)器獲取數(shù)據(jù)或創(chuàng)建新的紀錄時，他們是包裝在模型實例中 的，這意味著，我們的數(shù)據(jù)是面向?qū)ο蟮?，可以直接調(diào)用的數(shù)據(jù)和模型上定義的 任何功能或邏輯。也就是說，不是像下面這樣：var user = usersf

30、oo;destroyuser (user);我們應該像卜面這樣操作：var user = user .fin d("foo)；user. destroy ();第一個例子屮的實體不是命名空間或而向?qū)ο?，如果我們在我們的應用程?中定義了另一個destroyuser ()函數(shù)，那么兩者將發(fā)生沖突。全局變量和函數(shù) 應始終保持在絕對最小。在第二個例了中，destroy ()函數(shù)的命名空間在user 實例之后，相當于包含了 user實例里存儲的所有記錄。這也是一種解決的方法，因為我們的全局變量始終保持最小，減少了暴露的 潛在沖突。這樣的話代碼就更為簡潔并且可以繼承，正如destroy ()方

31、法并不 需要在每一個模型里分別定義。在第3章節(jié)屮我們會對模型進行更為深入的探討，其屮包括從服務(wù)器的數(shù)據(jù) 加載和創(chuàng)建對象關(guān)系映射等。視圖：視圖層是呈現(xiàn)給用戶看到的畫面。在javascript應用程序屮，視圖大部是 由html, css和javascript模版組成。除了模版中簡單的條件語句，視圖層中 不應該包含任何邏輯。事實上，比如模型，視圖應該也町以從應用程序的其它部分獨立出來。視圖 應該和控制器和模型沒有任何關(guān)系，它們應該是完全獨立的。將視圖和邏輯混朵在一起必將使應用程序走向崩潰。這并不是說mvc不允許有表彖的邏輯，只要它沒有定義在視圖中，而是駐留 在所謂的輔助變量中：專為一些小功能準備的視圖腳本。下面的例子，其屮包括視圖內(nèi)部的邏輯，這是你不應該做的事情：/ template, html<di v&g