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

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è)計(jì)在我們開始進(jìn)入spring mvc的神秘世界的旅程之前，我們首先要了解web應(yīng) 用程序的不同層。簡要介紹了mvc模式，我們將開始討

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

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

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

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

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

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