電子商務的三層架構

Ⅰ 怎樣理解MVC三層架構

『一個良好的JSP頁面不能出現「<%……%>」』
並不是這樣的，只是能不過多的出現而已。這是不同的。
JSP中，「<%……%>」裡面的java代碼是可以有一些業務邏輯的，而三層架構正是要將業務邏輯從頁面中分離出來，因些不要過多的使用「<%……%>」，但根據實際情況，適量的添加一些是可以的。
而MVC呢，實際上其實是一種架構模式，而不應該歸入設計模式了，設計模式是在代碼層面上說的：你的類都是什麼樣子的。
MVC，是架構層面是的：你的項目框架是怎麼設計的。

Ⅱ 電子商務網站一般架構有哪些

大型電子商務網站架構，摘抄 7.同一個網站的多語言該如何處理是好,使用配置文件然後cookie或url來判別?===客戶是自己公司，使用標准方法即可
8.電子商務網站最多的就是 商品的打折方式和積分的贈送了,這里要怎麼設計才好(工廠模式)?===采購成熟的規則引擎
9.如果同一時間並發大量訂單的話,如果確保一個訂單的有效提交呢?
==電子商務一般要使用MQ，推薦IBM MQ；使用MSMQ也可
第一點是資料庫要設計好，要達到什麼級別，你可能需要考慮哪些表需要拆分，哪些表的核心數據需要冗餘，如果是mysql，還要考慮其他的問題，比如存儲引擎。
新聞肯定是要生成純靜態頁，對資料庫壓力就小很多，不過靜態頁也有管理上的不方便，更新刪除添加都要對磁碟文件進行操作
做一個自定義緩存層，對緩存邏輯進行控制，可以採用第三方緩存模塊，如果使用.net來做，可以層層緩存，頁面緩存，數據緩存（memcache，不過在win下效率不高）
電子商務網站特點就是對事務的嚴格，需要資料庫設計的時候要求高性能，也需要合適的索引，支持高並發，經常對產品表用戶表等進行索引檢查，是否有很多索引掃描和表掃描（即使是局部的，也要將逗局部地控制到最小范圍）
mssql語句對不需要事務的查詢要附帶上with(nolock),以利於並發更新。
有些功能模塊不能按照想當然的方式開發，比如產品訪問次數，切不可將這些更新非常頻繁的欄位置於核心表內，明確的做法是將其剝離開來 還有就是切不可經常性將欄位設計成bool類型，這樣會給以後的擴展留出路，即使是男女這種欄位，也建議採用tiny類型
其他還有就是在產品設計的時候充分考慮seo，網站目錄結構清晰可讀，而不是帶著一串串的查詢參數。
對安全要有整體的把握，最好全都是用存儲過程，在項目上線前將資料庫存儲過程全部導出再查找貌似exec的語句，查找是否需要替換成sp_executesql。
另外，如果採用mssql，全文搜索直接用mssql fte就可以，速度和精確度都還是可以的，最重要的是維護和管理開發很簡單。
打折的處理可以按照電信的一次，二次批價功能，如果你做過電信方面的系統。
當然也可以設計得更簡單的一些。 靜態的頁面建議使用CDN加速，以解決網通和電信之間訪問速度的問題；
數據的緩存方面建議考慮用memcache，另外也可以分別在表現層和數據層利用.net中的現存緩存機製作業可；
簡單執行的sql可以不用存儲過程，存儲過程會佔用資料庫伺服器的處理時間，造成死鎖；
mvc建議還是做些CMS的項目上應用，電子商城不是很適合，個人觀點。url上可以做轉義，使url顯示更友好；
資料庫建議建立分布資料庫，這樣可以轉移查詢和大訪問量對資料庫帶來壓力；
圖片可以考慮單獨放在一台伺服器上；1.三層架構
2.使用手寫sql,手寫entity(生成也可),緩存反射綁定(不是緩存數據哦,緩存映射關系),要考慮網站的長期發展還是手寫吧 靈活 性能也好
3.沒有這種問題,商業驅動的,純購物就好了,千萬別搞什麼圈子,wiki
4.純.net的mvc不建議,webform不搞viewstate,不搞服務端控制項(除repeater)再加點mvc的思想已足夠用了
5.不需要緩存數據(除搜索產品部分),要考慮多台伺服器的程序快速部署,config文件會很多,config要序列化緩存
6.當然是先生成好了,參照jd吧,按業務每張圖片對應幾個不同大小的圖
7.據經驗,電子商務網站僅靠中英雙語來達到多語言是不靠譜的(文化 用戶習慣不是簡單的語言切換),如果想真正運營英語的就要重新開發一個版本
8.不搞模式
9.負載均衡(web,db)+ssb非同步處理數據
10.你是業務類型的日誌還是異常日誌? 前台訂單流程上異常日誌不需要了,找個工具錄個腳本不停的跑 保證隨時發現問題發郵件就可以了
11.找第三方搜索組件 類似endeca的
12.負載均衡挺簡單的,初期靠軟體就可以,一切圖片找第三方放cdn,前台網站用到ajax的地方很少,如果用的話jquery 1，一個電子商務網站用戶99.5%的行為時Find
2、對於商品檢索部分，能不用資料庫就不用資料庫（網上切詞等相關的開源平台很多）
3、分布式緩存（Memcached 、Volecity），個人測試volecity 3還是不錯的
4、系統設計時必須要考慮可運營。從這個角度去設計系統
5、對於電子商務網站改動很頻繁，必須考慮架構設計如何適應頻繁的版本更新
6、必須設計一個好的單點登錄系統。
7、建議能不用sqlserver就不用它。
8、對於大型電子商務網站來說，系統的I/O是起決定因素而不是CPU和內存。1.項目劃分是否會有問題,圖中分別是 實體層,數據訪問介面層,數據訪問層,業務邏輯介面層,業務邏輯,網站A,B,C
項目劃分其實不重要，重要的的是你在寫代碼的時候是否能把代碼合理的分到對應的項目里。
2.數據訪問層是要開發效率(NBear,Linq,Nh等),還是訪問效率(直接使用sql等)?是否可以先使用開發效率高的,等日後訪問量大了,再重寫並替換數據訪問層?
開發效率優先，訪問量大了以後，我相信是有錢投到硬體上的，在你程序寫的不是很爛的情況下，升級硬體遠比優化程序節省成本。
3.網站被切割成了多個子網站,有一些控制項(如header,footer)是要共享的,如何跨網站項目共享這些控制項呢?
那就做成自定義控制項啦。
4.ms的mvc 1.0也出來不少時間了,是否已經夠成熟運用到項目中?或者是網站後台使用webform的,前台使用mvc?
推薦使用使用webform的,前台使用mvc，對於前台來說使用mvc能更好的提升性能，更方便的更換頁面表現形式。後台界面相對穩定，用webform可以提高開發效率。
5.網站數據的緩存是自己開發一個hashtable什麼的來維護呢,還是使用Memcached ?
初期建議用hashtable，因為簡單，將來升級到Memcached 。
6.縮略圖的處理,我看有的網站是在上傳圖片的時候直接生成,有的是在httpmodle里處理,訪問的時候生成.
直接生成縮略圖的好處是節約性能。httpmodle相反，每次瀏覽圖片的時候都會生成新的圖片，伺服器壓力大，建議直接生成。
7.同一個網站的多語言該如何處理是好,使用配置文件然後cookie或url來判別?
多語言建議使用asp.net自帶的資源文件的方式實現，當前語言保存在cookie裡面。
8.電子商務網站最多的就是 商品的打折方式和積分的贈送了,這里要怎麼設計才好(工廠模式)?
規則引擎
9.如果同一時間並發大量訂單的話,如果確保一個訂單的有效提交呢?
使用MQ隊列
10.日誌方面,log4net?
log4net只能記錄程序運行日誌，主要目的是用來調試程序的，系統業務操作日誌還你是得自己建一個表來保存。
11.電子商務的全文檢索,這也是個頭疼的問題
lucene，微軟索引服務，sqlserver全文檢索，方案很多的。
12.負載均衡方面,有什麼好的文章推薦碼?
可以看windows 2003 集群方面的文章 1.項目劃分是否會有問題,圖中分別是 實體層,數據訪問介面層,數據訪問層,業務邏輯介面層,業務邏輯,網站A,B,C
目前我也是這樣分的,不過當數據表結構有修改時,會帶動其它層的聯級修改,非常不方便，所以開發之前最好將資料庫設計地完善一點。另外，當網站分成多個以後，其它項目生成的DLL文件要部署到每個網站的bin文件夾里，更新一次都要重新部署，這也是個挺煩人的事，當然可以將DLL部署到GAC里來解決這個問題，不過這樣的話本地調試起來就不太方便了，因為項目一有改動，就要將生成的DLL重新拷貝到GAC里才能看到效果。
2.數據訪問層是要開發效率(NBear,Linq,Nh等),還是訪問效率(直接使用sql等)?是否可以先使用開發效率高的,等日後訪問量大了,再重寫並替換數據訪問層?
這個我也在考慮。目前我還沒有採用ORM框架，都是在DAL里直接訪問DB的。
3.網站被切割成了多個子網站,有一些控制項(如header,footer)是要共享的,如何跨網站項目共享這些控制項呢?
自定義控制項。
4.ms的mvc 1.0也出來不少時間了,是否已經夠成熟運用到項目中?或者是網站後台使用webform的,前台使用mvc?
正在學習這一塊。
5.網站數據的緩存是自己開發一個hashtable什麼的來維護呢,還是使用Memcached ?
現在我用的比較多的是.net自帶的數據緩存。
6.縮略圖的處理,我看有的網站是在上傳圖片的時候直接生成,有的是在httpmodle里處理,訪問的時候生成.
直接生成好，快一點。
7.同一個網站的多語言該如何處理是好,使用配置文件然後cookie或url來判別?
我沒涉及到這一塊，不過我覺得資源文件應該就是用來處理這個問題的。
8.電子商務網站最多的就是 商品的打折方式和積分的贈送了,這里要怎麼設計才好(工廠模式)?
這些都放在邏輯層好了。
9.如果同一時間並發大量訂單的話,如果確保一個訂單的有效提交呢?
MSMQ
10.日誌方面,log4net?
目前我是自已寫代碼存在庫里的。
11.電子商務的全文檢索,這也是個頭疼的問題
用lucene.net分詞建索引，再直接從索引庫里搜索，又快又准。
12.負載均衡方面,有什麼好的文章推薦碼?
不清楚了。 這樣的設計要達到新蛋的效果肯定不可能的，新蛋少說幾百台伺服器，不同資料庫之間的發布訂閱鏈路都有幾千條。有復雜的緩存，負載均衡機制。新蛋所有的通訊都是基於WCF的。另外對於這么大型的網站來說，資料庫一刻都不停止，所以讀寫分離也很重要，因為你也不可能讓資料庫停下來進行備份。總歸要做到新蛋這樣的大型電子商務網站，靠你上面畫的這點好像遠遠不夠。
不過關於公共的header,footer,我不建議做成自定義控制項，這個維護起來不方便，稍有變動就要發布dll，麻煩的。
如果你的header和footer不是很大的話，建議採用js+css的方式。然後加上壓縮和cdn緩存，應該效率上能接受。

Ⅲ 電子商務ERP軟體C/S架構和B/S架構的區別

C/S 架構

C/S 架構是一種典型的兩層架構，其全程是Client/Server，即客戶端伺服器端架構，其客戶端包含一個或多個在用戶的電腦上運行的程序，而伺服器端有兩種，一種是資料庫伺服器端，客戶端通過資料庫連接訪問伺服器端的數據；另一種是Socket伺服器端，伺服器端的程序通過Socket與客戶端的程序通信。

B/S架構

B/S 架構的全稱為Browser/Server，即瀏覽器/伺服器結構。Browser指的是Web瀏覽器，極少數事務邏輯在前端實現，但主要事務邏輯在伺服器端實現，Browser客戶端，WebApp伺服器端和DB端構成所謂的三層架構。

B/S架構的系統無須特別安裝，只有Web瀏覽器即可。

B/S架構中，顯示邏輯交給了Web瀏覽器，事務處理邏輯在放在了WebApp上，這樣就避免了龐大的胖客戶端，減少了客戶端的壓力。因為客戶端包含的邏輯很少，因此也被成為瘦客戶端。

C/S和B/S都可以進行同樣的業務處理，但是B/S隨著Internet技術的興起，是對C/S結構的一種改進或者擴展的結構。相對於C/S，B/S具有如下優勢：

1、分布性：可以隨時進行查詢、瀏覽等業務

2、業務擴展方便：增加網頁即可增加伺服器功能

3、維護簡單方便：改變網頁，即可實現所有用戶同步更新

4、開發簡單，共享性強，成本低，數據可以持久存儲在雲端而不必擔心數據的丟失。

Ⅳ 三層架構是什麼

MVC是三個單詞的縮寫,分別為： 模型(Model),視圖(View)和控制Controller)。 MVC模式的目的就是實現Web系統的職能分工。 Model層實現系統中的業務邏輯，通常可以用JavaBean或EJB來實現。 View層用於與用戶的交互，通常用JSP來實現。 Controller層是Model與View之間溝通的橋梁，它可以分派用戶的請求並選擇恰當的視圖以用於顯示，同時它也可以解釋用戶的輸入並將它們映射為模型層可執行的操作。

目錄

MVC與模板概念的理解
MVC如何工作視圖
模型
控制器
為什麼要使用 MVC
MVC的優點低耦合性
高重用性和可適用性
較低的生命周期成本
快速的部署
可維護性
有利於軟體工程化管理
MVC的缺點
開發方式Java開發Web Application
.NET開發Web Application
php 開發Web Application
常見的MVC組件
Struts 中Model 1 和Model 2簡介Model 1
Model 2
Struts的結構和處理流程簡介
利用Struts框架開發
MVC與模板概念的理解
MVC(Model View Controller)模型－視圖－控制器 MVC本來是存在於Deskt
op程序中的，M是指數據模型，V是指用戶界面，C則是控制器。使用MVCright: Apple Inc.
的目的是將M和V的實現代碼分離，從而使同一個程序可以使用不同的表現形式。比如一批統計數據你可以分別用柱狀圖、餅圖來表示。C存在的目的則是確保M和V的同步，一旦M改變，V應該同步更新。 模型－視圖－控制器（MVC）是Xerox PARC在八十年代為編程語言Smalltalk－80發明的一種軟體設計模式，至今已被廣泛使用。最近幾年被推薦為Oracle旗下Sun公司Java EE平台的設計模式，並且受到越來越多的使用 ColdFusion 和 PHP 的開發者的歡迎。模型－視圖－控制器模式是一個有用的工具箱，它有很多好處，但也有一些缺點。
MVC如何工作
MVC是一個設計模式，它強制性的使應用程序的輸入、處理和輸出分開。使用MVC應用程序被分成三個核心部件：模型、視圖、控制器。它們各自處理自己的任務。
視圖
視圖是用戶看到並與之交互的界面。對老式的Web應用程序來說，視圖就是由HTML元素組成的界面，在新式的Web應用程序中，HTML依舊在視圖中扮演著重要的角色，但一些新的技術已層出不窮，它們包括Macromedia Flash和象XHTML，XML/XSL，WML等一些標識語言和Web services. 如何處理應用程序的界面變得越來越有挑戰性。MVC一個大的好處是它能為你的應用程序處理很多不同的視圖。在視圖中其實沒有真正的處理發生，不管這些數據是聯機存儲的還是一個雇員列表，作為視圖來講，它只是作為一種輸出數據並允許用戶操縱的方式。
模型
模型表示企業數據和業務規則。在MVC的三個部件中，模型擁有最多的處理任務。例如它可能用象EJBs和ColdFusion Components這樣的構件對象來處理資料庫。被模型返回的數據是中立的，就是說模型與數據格式無關，這樣一個模型能為多個視圖提供數據。由於應用於模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復性。
控制器
控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求。所以當單擊Web頁面中的超鏈接和發送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求並決定調用哪個模型構件去處理請求，然後再確定用哪個視圖來顯示返回的數據。
為什麼要使用 MVC
大部分Web應用程序都是用像ASP，PHP，或者CFML這樣的過程化(自PHP5.0版本後已全面支持面向對象模型)語言來創建的。它們將像資料庫查詢語句這樣的數據層代碼和像HTML這樣的表示層代碼混在一起。經驗比較豐富的開發者會將數據從表示層分離開來，但這通常不是很容易做到的，它需要精心的計劃和不斷的嘗試。MVC從根本上強制性的將它們分開。盡管構造MVC應用程序需要一些額外的工作，但是它給我們帶來的好處是毋庸置疑的。 首先，最重要的一點是多個視圖能共享一個模型，現在需要用越來越多的方式來訪問你的應用程序。對此，其中一個解決之道是使用MVC，無論你的用戶想要Flash界面或是 WAP 界面；用一個模型就能處理它們。由於你已經將數據和業務規則從表示層分開，所以你可以最大化的重用你的代碼了。 由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同界面使用。例如，很多數據可能用HTML來表示，但是它們也有可能要用Adobe Flash和WAP來表示。模型也有狀態管理和數據持久性處理的功能，例如，基於會話的購物車和電子商務過程也能被Flash網站或者無線聯網的應用程序所重用。 因為模型是自包含的，並且與控制器和視圖相分離，所以很容易改變你的應用程序的數據層和業務規則。如果你想把你的資料庫從MySQL移植到Oracle，或者改變你的基於RDBMS數據源到LDAP，只需改變你的模型即可。一旦你正確的實現了模型，不管你的數據來自資料庫或是LDAP伺服器，視圖將會正確的顯示它們。由於運用MVC的應用程序的三個部件是相互獨立，改變其中一個不會影響其它兩個，所以依據這種設計思想你能構造良好的松耦合的構件。 對我來說，控制器也提供了一個好處，就是可以使用控制器來聯接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據用戶的需求選擇模型進行處理，然後選擇視圖將處理結果顯示給用戶。
MVC的優點
低耦合性
視圖層和業務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的業務流程或者業務規則的改變只需要改動MVC的模型層即可。因為模型與控制器和視圖相分離，所以很容易改變應用程序的數據層和業務規則。
高重用性和可適用性
隨著技術的不斷進步，現在需要用越來越多的方式來訪問應用程序。MVC模式允許你使用各種不同樣式的視圖來訪問同一個伺服器端的代碼。它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，用戶可以通過電腦也可通過手機來訂購某樣產品，雖然訂購的方式不一樣，但處理訂購產品的方式是一樣的。由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同的界面使用。例如，很多數據可能用HTML來表示，但是也有可能用WAP來表示，而這些表示所需要的命令是改變視圖層的實現方式，而控制層和模型層無需做任何改變。
較低的生命周期成本
MVC使降低開發和維護用戶介面的技術含量成為可能。
快速的部署
使用MVC模式使開發時間得到相當大的縮減，它使程序員（Java開發人員）集中精力於業務邏輯，界面程序員（HTML和JSP開發人員）集中精力於表現形式上。
可維護性
分離視圖層和業務邏輯層也使得WEB應用更易於維護和修改。
有利於軟體工程化管理
由於不同的層各司其職，每一層不同的應用具有某些相同的特徵，有利於通過工程化、工具化管理程序代碼。
MVC的缺點
MVC的缺點是由於它沒有明確的定義，所以完全理解MVC並不是很容易。使用MVC需要精心的計劃，由於它的內部原理比較復雜，所以需要花費一些時間去思考。 你將不得不花費相當可觀的時間去考慮如何將MVC運用到你的應用程序，同時由於模型和視圖要嚴格的分離，這樣也給調試應用程序帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。一旦你的構件經過了測試，你就可以毫無顧忌的重用它們了。 根據開發者經驗，由於開發者將一個應用程序分成了三個部件，所以使用MVC同時也意味著你將要管理比以前更多的文件，這一點是顯而易見的。這樣好像我們的工作量增加了，但是請記住這比起它所能帶給我們的好處是不值一提。 MVC並不適合小型甚至中等規模的應用程序，花費大量時間將MVC應用到規模並不是很大的應用程序通常會得不償失。 MVC設計模式是一個很好創建軟體的途徑，它所提倡的一些原則，像內容和顯示互相分離可能比較好理解。但是如果你要隔離模型、視圖和控制器的構件，你可能需要重新思考你的應用程序，尤其是應用程序的構架方面。如果你肯接受MVC，並且有能力應付它所帶來的額外的工作和復雜性，MVC將會使你的軟體在健壯性，代碼重用和結構方面上一個新的台階。
開發方式
Java開發Web Application
Java開發Web Application有幾種符合MVC設計模式的開發方式。 1:Jsp+Servlet+JavaBean(EJB) 2:Jsp+JavaBean(Controller)+JavaBean(EJB)(Model) 3:TDK(Turbine，Velocity...) 4:Xsp 5:Jsp+Struts+JavaBean(EJB) 6:SSH (Struts + Spring + Hibernate)
.NET開發Web Application
.NET開發Web Application可以採用： 1:ASP.NET MVC Framework（ASP.NET MVC ） 2:MonoRail (RC3) 3:ASP.NET MVC2
php 開發Web Application
php 開發Web Application 可以採用： 1. Zend framework PHP官方框架 2. fleaphp/Qeephp 等國內流行框架 3. CakePHP 等國外流行框架 4. ThinkPHP 等其他框架
常見的MVC組件
Struts： Apache的，最流行的MVC組件 Struts2 ：Apache用Struts 和 WebWork的組合出來的新產品，目前上升勢頭強勁 WebWork： 這個可是老牌的MVC組件，後來組合成了Struts2, 不過自身仍在發展 Spring MVC：SpringFramework自己整合自己Spring的優勢推出的MVC組件，用戶也不少 JSF： 這個是一個規范，Sun的和 Apache的都有各自的實現。用戶量很大，被眾多IDE支持。 Tapestry： 最徹底的MVC開發框架，豐富的組件資源，重用性很高。組件扮演著控制器Controller的角色，是模式層（Model） 中pure-domain objects和包含有組件的HTML模板之間的媒介。大多數情況下，這種方式應用於頁面（頁面也 是 Tapestry組件），但是在某些情況中，一個組件擁有自己的模板，包含著更多的組件，並且支持與使用者的互交。頁面通過配置一系列屬性表達式（Property expressions）連接模式層和表現層。屬性表達式使用另外一種開源框架OGNL（Object Graph Navigation Language）。OGNL的開源工程（project）獨立於Tapestry，但是在Tapestry中起很重要的作用。OGNL主要的目的在於讀取和更新對象的Java Bean屬性。 .net mvc：在.net上的mvc組件，經過了preview1~5，RC1，RC2，目前已經是正式版了，微軟給出的定義是可以用於生產的架構。配合VS2008以及將要出現的VS2010，相信.net mvc將會是MVC家族的重要的一員。
Struts 中Model 1 和Model 2簡介
我們在開發Web應用時經常提到的一個概念是Model1/Model2，那麼到底它是什麼意思呢？其實它是對採用JSP技術構成Web應用的不同模型的描述。下面對這個概念做一個簡單的介紹。
Model 1
在使用JAVA技術建立Web應用的實例中，由於JSP技術的發展，很快這種便於掌握和可實現快速開發的技術就成了創建Web應用的主要技術。JSP頁面中可以非常容易地結合業務邏輯（jsp:useBean）、服務端處理過程（jsp:let）和HTML（），在JSP頁面中同時實現顯示，業務邏輯和流程式控制制，從而可以快速地完成應用開發。現在很多的Web應用就是由一組JSP頁面構成的。這種以JSP為中心的開發模型我們可以稱之為Model1。 當然這種開發模式在進行快速和小規模的應用開發時，是有非常大的優勢，但是從工程化的角度考慮，它也有一些不足之處： 應用的實現一般是基於過程的，一組JSP頁面實現一個業務流程，如果要進行改動，必須在多個地方進行修改。這樣非常不利於應用擴展和更新。 由於應用不是建立在模塊上的，業務邏輯和表示邏輯混合在JSP頁面中沒有進行抽象和分離。所以非常不利於應用系統業務的重用和改動。 考慮到這些問題在開發大型的Web應用時必須採用不同的設計模式――這就是Model2
Model 2
Model 2表示的是基於MVC模式的框架。MVC是Model－View－Controller的簡寫。「Model」代表的是應用的業務邏輯（通過JavaBean，EJB組件實現），「View」是應用的表示面（由JSP頁面產生），「Controller」是提供應用的處理過程式控制制（一般是一個Servlet），通過這種設計模型把應用邏輯，處理過程和顯示邏輯分成不同的組件實現。這些組件可以進行交互和重用。從而彌補了Model1的不足。 Model2具有組件化的優點從而更易於實現對大規模系統的開發和管理，但是開發StrutsMVC系統比簡單的JSP開發要復雜許多，它需要更多的時間學習和掌握。同時新東西的引入會帶來新的問題（這讓我想起來關於「自動計算」的一篇文章，中間提到為了降低系統的復雜度，卻導致更高的復雜度）。 必須基於StrutsMVC組件的方式重新思考和設計應用結構。原來通過建立一個簡單的JSP頁面就能實現的應用現在變成了多個步驟的設計和實現過程。 所有的頁面和組件必須在Struts MVC框架中實現，所以必須進行附加地開發工作。 StrutsMVC本身就是一個非常復雜的系統，所以採用StrutsMVC實現Web應用時，最好選一個現成的MVC框架，在此之下進行開發，從而取得事半功倍的效果。現在有很多可供使用的MVC框架，由於Struts有完整的文檔並且相對來講比較簡單，所以用它開發MVC系統還是比較方便地。
Struts的結構和處理流程簡介
Struts1是Apache組織的一個項目，像其他的Apache組織的項目一樣，它也是開放源碼項目。Struts1是一個比較好的MVC框架提供了對開發MVC系統的底層支持，它採用的主要技術是Servlet，JSP和customtaglibrary。 作為一個MVC的框架，Struts1對Model、View和Controller都提供了對應的實現組件，分別進行介紹，並且看看它們是如何結合在一起的。 Controller：控制器的作用是從客戶端接受請求，並且選擇執行相應的業務邏輯，然後把響應結果送回到客戶端。在Struts1中Controller功能由圖中ActionServlet和ActionMapping對象構成：核心是一個Servlet類型的對象ActionServlet，它用來接受客戶端的請求。ActionServlet包括一組基於配置的ActionMapping對象，每個ActionMapping對象實現了一個請求到一個具體的Model部分中Action處理器對象之間的映射。 Model：StrutsMVC系統中的Model部分從概念上可以分為兩類――系統的內部狀態，和改變系統狀態的動作。Struts1為Model部分提供了Action和ActionForm對象：所有的Action處理器對象都是開發者從Struts1的Action類派生的子類。Action處理器對象封裝了具體的處理邏輯，調用業務邏輯模塊，並且把響應提交到合適的View組件以產生響應。Struts1提供的ActionForm組件對象，它可以通過定義屬性描述客戶端表單數據。開發者可以從它派生子類對象，利用它和Struts提供的自定義標記庫結合可以實現對客戶端的表單數據的良好封裝和支持，Action處理器對象可以直接對它進行讀寫，而不再需要和request、response對象進行數據交互。通過ActionForm組件對象實現了對View和Model之間交互的支持。Struts1通常建議使用一組JavaBean表示系統的內部狀態，根據系統的復雜度也可以使用像EntityEJB和SessionEJB等組件來實現系統狀態。Struts建議在實現時把「做什麼」（Action）和「如何做」（業務邏輯）分離。這樣可以實現業務邏輯的重用。 View：Struts1應用中的View部分是通過JSP技術實現的。Struts1提供了自定義的標簽庫(tag library)可以使用，通過這些自定義標簽(tag)可以非常好地和系統的Model部分交互，通過使用這些自定義標簽創建的JSP表單，可以實現和Model部分中的ActionForm的映射，完成對用戶數據的封裝，同時這些自定義標簽還提供了像模板定製等多種顯示功能。 StrutsMVC框架的處理流程清楚的體現了MVC系統的特點，簡單的Struts組件結構。StrutsControllerActionServlet處理客戶請求，利用配置的ActionMapping對象把請求映射到Action處理器對象進行處理。Action處理對象訪問ActionForm中的數據，處理和響應客戶請求，它還調用後台的Bean組件，這些組件封裝了具體的業務邏輯。Action處理器對象根據處理結果通知Controller，Controller進行下一步的處理。
利用Struts框架開發
Struts1 MVC系統要做的工作 由於Struts已經為我們提供了一個非常好的MVC框架，我們利用Struts開發MVC系統時可以大大加快開發的速度。在開發時可以採用的一個開發流程如下（引自資料3）： 收集和定義應用需求。 基於數據採集和顯示的原則定義和開發「屏幕顯示」需求 。 為每一個「屏幕顯示」定義訪問路徑。 定義ActionMappings建立到應用業務邏輯之間的聯系。 開發滿足「屏幕顯示」需求的所有支持對象。 基於每一個「屏幕顯示」需求提供的數據屬性來創建對應的ActionForm對象 開發被ActionMapping調用的Action對象。 開發應用業務邏輯對象 （Bean，EJB，等等）。 對應ActionMapping設計的流程創建JSP頁面。 建立合適的配置文件struts-config.xml ， web.xml。 開發/測試/部署 具體在使用Struts框架時，對應各個部分的開發工作主要包括： Model部分：採用JavaBean和EJB組件，設計和實現系統的業務邏輯。根據不同的請求從Action派生具體Action處理對象。完成「做什麼」的任務來調用由Bean構成的業務組件。創建由ActionForm的派生類實現對客戶端表單數據的封裝。 Controller部分：Struts為我們提供了核心控制部分的實現。我們只需要配置ActionMapping對象 View部分：為了使用Model中的ActionForm對象，我們必須用Struts提供的自定義標記創建HTML表單。利用Struts提供的自定義標記庫編寫用戶界面把應用邏輯和顯示邏輯分離。Struts框架通過這些自定義標記建立了View和Model之間的聯系。Struts的自定義標記還提供了很多定製頁面的功能。 同時需要編輯兩個配置文件：web.xml和struts-config.xml。通過它們配置Struts系統中的各個模塊之間的交互。下面對這兩個配置文件做一些介紹： web.xml文件的配置： web應用中的web.xml是第一個要配置的地方，它描述了系統的Controller對象。在web.xml中增加如下標記 <servlet><servlet-name>action</servlet-name><servlet-class> org.apache.struts.action.ActionServlet</servlet-class><init-m> <m-name>application</m-name> </servlet> 說明：這個servlet對象就是Struts提供的Controller，還可以為它指定初始化參數，比如對系統應用屬性的支持。 < SERVLET-MAPPING> < SERVLET-NAME>action</SERVLET-NAME>< URL-PATTERN>*.do</URL-PATTERN></SERVLET-MAPPING> 說明：實現客戶請求的url信息和伺服器端具體處理的映射關系。 <taglib><taglib-url>/WEB-INF/struts-bean.tld</taglib-url> <taglib-location>/WEB-INF/struts-bean.tld</taglib-location></taglib> 說明：添加對Struts提供的應用所使用的自定義標記庫的引用。 struts-config.xml文件的配置： struts-config.xml是用於建立Controller和Model之間的關系的。它描述了Controller所使用的把請求對應到具體處理的法則，同時它還描述了客戶提供的數據與ActionForm組件的對應映射關系。 在struts-config.xml中增加如下標記 <form-beans> <form-bean name=「loginForm」type=「loginForm」/></form-beans> 說明：標記描述一個具體的ActionForm子類對象，通過它和JSP頁面中的自定標記的結合使用可以實現ActionForm和View之間的數據映射。 <action-mappings><actionpath=「/login」type=「loginAction」 name=「loginForm」input=「/login.jsp」/></action-mappings> 說明：標記描述了請求和處理的一對一映射關系。input和path屬性唯一的標記了客戶端的一個請求，name屬性描述封裝客戶端的數據的ActionForm子類對象。Type屬性描述處理這個請求的Action子類對象。 [1]通過對兩個配置文件的配置，把Struts MVC框架中MVC的各個部分聯系起來，實現一個真正的Struts MVC系統。

Ⅳ 三層架構和mvc模式有什麼關系

三層架構和MVC是有明顯區別的,MVC應該是展現模式(三個加起來以後才是三層架構中的UI層) 三層架構(3-tier
application)
通常意義上的三層架構就是將整個業務應用劃分為：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。區分層次的目的即為了「高內聚，低耦合」的思想。
1、表現層（UI）：通俗講就是展現給用戶的界面，即用戶在使用一個系統的時候他的所見所得。
2、業務邏輯層（BLL）：針對具體問題的操作，也可以說是對數據層的操作，對數據業務邏輯處理。
3、數據訪問層（DAL）：該層所做事務直接操作資料庫，針對數據的增添、刪除、修改、更新、查找等。
MVC是
Model-View-Controller，嚴格說這三個加起來以後才是三層架構中的UI層，也就是說，MVC把三層架構中的UI層再度進行了分化，分成了控制器、視圖、實體三個部分，控制器完成頁面邏輯，通過實體來與界面層完成通話；而C層直接與三層中的BLL進行對話。
mvc可以是三層中的一個表現層框架，屬於表現層。三層和mvc可以共存。
三層是基於業務邏輯來分的，而mvc是基於頁面來分的。
MVC主要用於表現層，3層主要用於體系架構，3層一般是表現層、中間層、數據層，其中表現層又可以分成M、V、C，(Model View
Controller)模型－視圖－控制器

曾把MVC模式和Web開發中的三層結構的概念混為一談，直到今天才發現一直是我的理解錯誤。MVC模式是GUI界面開發的指導模式，基於表現層分離的思想把程序分為三大部分：Model-View-Controller，呈三角形結構。Model是指數據以及應用程序邏輯，View是指

Model的視圖，也就是用戶界面。這兩者都很好理解，關鍵點在於Controller的角色以及三者之間的關系。在MVC模式中，Controller和View同屬於表現層，通常成對出現。Controller被設計為處理用戶交互的邏輯。一個通常的誤解是認為Controller負責處理View和Model的交互，而實際上View和Model之間是可以直接通信的。由於用戶的交互通常會涉及到Model的改變和View的更新，所以這些可以認為是Controller的副作用。
MVC是表現層的架構，MVC的Model實際上是ViewModel，即供View進行展示的數據。
ViewModel不包含業務邏輯，也不包含數據讀取。
而在N層架構中，一般還會有一個Model層，用來與資料庫的表相對應，也就是所謂ORM中的O。這個Model可能是POCO，也可能是包含一些驗證邏輯的實體類，一般也不包含數據讀取。進行數據讀取的是數據訪問層。而作為UI層的MVC一般不直接操作數據訪問層，中間會有一個業務邏輯層封裝業務邏輯、調用數據訪問層。UI層（Controller）通過業務邏輯層來得到數據（Model），並進行封裝（ViewModel），然後選擇相應的View。
MVC本來是存在於Desktop程序中的，M是指數據模型，V是指用戶界面，C則是控制器。使用MVC的目的是將M和V的實現代碼分離，從而使同一個程序可以使用不同的表現形式。比如一批統計數據你可以分別用柱狀圖、餅圖來表示。C存在的目的則是確保M和V的同步，一旦M改變，V應該同步更新。
MVC如何工作
MVC是一個設計模式，它強制性的使應用程序的輸入、處理和輸出分開。使用MVC應用程序被分成三個核心部件：模型、視圖、控制器。它們各自處理自己的任務。
視圖V
視圖是用戶看到並與之交互的界面。對老式的Web應用程序來說，視圖就是由HTML元素組成的界面，在新式的Web應用程序中，HTML依舊在視圖中扮演著重要的角色，但一些新的技術已層出不窮，它們包括Macromedia
Flash和象XHTML，XML/XSL，WML等一些標識語言和Web services.
如何處理應用程序的界面變得越來越有挑戰性。MVC一個大的好處是它能為你的應用程序處理很多不同的視圖。在視圖中其實沒有真正的處理發生，不管這些數據是聯機存儲的還是一個雇員列表，作為視圖來講，它只是作為一種輸出數據並允許用戶操縱的方式。
模型M
模型表示企業數據和業務規則。在MVC的三個部件中，模型擁有最多的處理任務。被模型返回的數據是中立的，就是說模型與數據格式無關，這樣一個模型能為多個視圖提供數據。由於應用於模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復性。
控制器C
控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求。所以當單擊Web頁面中的超鏈接和發送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求並決定調用哪個模型構件去處理請求，然後再確定用哪個視圖來顯示返回的數據。
模型Model 模型是應用程序的主體部分。模型表示業務數據，或者業務邏輯. 實現具體的業務邏輯、狀態管理的功能。 視圖View
視圖是應用程序中用戶界面相關的部分，是用戶看到並與之交互的界面。 就是與用戶實現交互的頁面，通常實現數據的輸入和輸出功能。
控制器controller
控制器工作就是根據用戶的輸入，控制用戶界面數據顯示和更新model對象狀態。起到控制整個業務流程的作用，實現View層跟Model層的協同工作。
3層架構指:表現層(顯示層)
業務邏輯層 數據訪問層(持久化)如果大家非要「生搬硬套」把它和MVC扯上關系話那我就只能在這里"強扭這個瓜"了即: V
3層架構中"表現層"aspx頁面對應MVC中View(繼承的類不一樣) C
三層架構中"表現層"的aspx.cs頁面(類)對應MVC中的Controller,理解這一點並不難，大家想一想我們以前寫過的
Redirect，當然它本身就是跳轉了一些鏈接頁面，而MVC中的Controller要做的更爽，它控制並顯示輸出了一個視圖。即然所起到的作用都是對業務流程和顯示信息的控制，只不過是實現手段不同而已。
M
3層架構中業務邏輯層和數據訪問層對應MVC中Model(必定View和Controller已找到「婆家」剩下Model只能是業務邏輯層和數據訪問層了)
為什麼要使用
MVC
大部分Web應用程序都是用像ASP，PHP，或者CFML這樣的過程化(自PHP5.0版本後已全面支持面向對象模型)語言來創建的。它們將像資料庫查詢語句這樣的數據層代碼和像HTML這樣的表示層代碼混在一起。經驗比較豐富的開發者會將數據從表示層分離開來，但這通常不是很容易做到的，它需要精心的計劃和不斷的嘗試。MVC從根本上強制性的將它們分開。盡管構造MVC應用程序需要一些額外的工作，但是它給我們帶來的好處是無庸質疑的。

首先，最重要的一點是多個視圖能共享一個模型，現在需要用越來越多的方式來訪問你的應用程序。對此，其中一個解決之道是使用MVC，無論你的用戶想要Flash界面或是
WAP 界面；用一個模型就能處理它們。由於你已經將數據和業務規則從表示層分開，所以你可以最大化的重用你的代碼了。
由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同界面使用。例如，很多數據可能用HTML來表示，但是它們也有可能要用Adobe
Flash和WAP來表示。模型也有狀態管理和數據持久性處理的功能，例如，基於會話的購物車和電子商務過程也能被Flash網站或者無線聯網的應用程序所重用。

因為模型是自包含的，並且與控制器和視圖相分離，所以很容易改變你的應用程序的數據層和業務規則。如果你想把你的資料庫從MySQL移植到Oracle，或者改變你的基於RDBMS數據源到LDAP，只需改變你的模型即可。一旦你正確的實現了模型，不管你的數據來自資料庫或是LDAP伺服器，視圖將會正確的顯示它們。由於運用MVC的應用程序的三個部件是相互獨立，改變其中一個不會影響其它兩個，所以依據這種設計思想你能構造良好的松耦合的構件。

對我來說，控制器也提供了一個好處，就是可以使用控制器來聯接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據用戶的需求選擇模型進行處理，然後選擇視圖將處理結果顯示給用戶。
拿一個簡單的登陸模塊說，需求是你輸入一個用戶名、密碼，如果輸入的跟預先定義好的一樣，那麼就進入到正確頁面，如果不一樣，就提示個錯誤信息「你Y別在這兒蒙我，輸入的不對！」。
V 這個小小的模塊中，起始的輸入用戶名密碼的頁面跟經過校驗後顯示的頁面就相當於View C
而這里還需要一個controller頁面，就是用於接收輸入進來的用戶名密碼，還有經過校驗後返回的一個flg（此flg就是用於判斷你輸入的是否正確，而跳轉到相應的頁面的）
M 最後還缺一個Model，那麼就是你那個用於校驗的類了，他就是處理你輸入的是否跟預先訂好的一樣不一樣的，之後返回一個flg。
這樣就完全實現了邏輯跟頁面的分離，我頁面不管你咋整，反正我就一個顯示，而controller呢也不管你Model咋判斷對不對，反正我給你了用戶名跟密碼，你就得給我整回來一個flg來，而Medol呢，則是反正你敢給我個用戶名跟密碼，我就給你整過去個flg
m 提供數據，數據之間的關系，轉化等。並可以通知視圖和控制器自己哪些地方發生了變化。 v 提供顯示，能根據m的改變來更新自己 c
比如視圖做了點擊一個按鈕，會先發給這個視圖的控制器，然後這個控制器來決定做什麼操作(讓模型更新數據，控制視圖改變) mvc是一個復合模式
mv，mc都是觀察者模式 m內部的組件組合模式 vc之間是策略模式(可以隨時更換不同的控制器)

MVC模式是上世紀70年代提出，最初用於Smalltalk平台上的。
MVC是表現模式，是用來向用戶展現的許多組建的一個模式（UI/Presentation Patten） MVC有三種角色：
Model：用來儲存數據的組件（與領域模型概念不同，兩者會相互交叉）
View：從Model中獲取數據進行內容展示的組件。同樣的Model在不同的View下可展示不同的效果。獲取Model的狀態，而不對其進行操作。
Controller：接受並處理用戶指令（操作Model（業務）），選擇一個View進行操作。

MVC概述：協作 存在單向引用，例如Model不知道View和Controller的存在。View不知道Controller的存在。這就隔離了表現和數據。View和controller是單向引用。而實際中View和Controller也是有數據交互的。

MVC的重要特點是分離。兩種分離： View和數據(Model)的分離
使用不同的View對相同的數據進行展示；分離可視和不可視的組件，能夠對Model進行獨立測試。因為分離了可視組件減少了外部依賴利於測試。（資料庫也是一種外部組件）
View和表現邏輯(Controller)的分離
Controller是一個表現邏輯的組件，並非一個業務邏輯組件。MVC可以作為表現模式也可以作為建構模式，意味這Controller也可以是業務邏輯。分離邏輯和具體展示，能夠對邏輯進行獨立測試。

MVC和三層架構 MVC與三層架構類似么？ View-UI Layer | Controller-Bussiness Layer
| Model-Data Access Layer 其實這樣是錯誤的 MVC是表現模式（Presentation Pattern）
三層架構是典型的架構模式（Architecture Pattern）
三層架構的分層模式是典型的上下關系，上層依賴於下層。但MVC作為表現模式是不存在上下關系的，而是相互協作關系。即使將MVC當作架構模式，也不是分層模式。MVC和三層架構基本沒有可比性，是應用於不同領域的技術。

MVC模式與三層架構:

ui (view)←(contorller)

***********************

bll (model)

***********************

dal (model)

Ⅵ 三層架構是做什麼的做購物車網站必須用到嗎用不到的話我就不學了。詳細點謝謝

表示層 --> 業務層 --> 持久層；系統開發都必須有這三層的架構。表示層是主要是做展示的，購物車網站不就是一個電子商務系統嘛，做得再簡單也必須有商品展示（表示層），訂單處理（業務層），還有就是用資料庫存儲各種信息（持久層）。這三層架構要學的話，包含的技術很多，學會這三層的東西基本上就能開發系統了。

Ⅶ 三層架構和mvc的區別是什麼

三層架構將整個項目劃分為：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。

MVC 即Model（模型），View（視圖），Controller（控制）。

下面看一下他倆的區別與聯系：

通過這個圖我們可以知道，我們平常所說的V是UI，C是BLL，M是DAL的觀點是錯誤的。

而我們通常所見到的MVC一般也都是在應用三層架構的基礎上，即將Model層再進行分層。而如果Model不再進行劃分的話，那麼使用MVC的意義也就不大了。

然後，它倆的目的著重點不同。

三層架構的目的著重點是「高內聚，低耦合」，即解耦。

MVC的目的則是實現Web系統的職能分工，即職責劃分。

其實職責劃分也是解耦，但是三層側重的是整體的一個解耦，而MVC側重的是web系統的解耦，即側重jsp和Servlet的一個解耦。

最後，為何我們會將其混為一談？

既然兩者有這么多的不同，我們為什麼還總是將其混淆呢，下面我列舉了幾個我們常常將其混為一談的幾個原因：

1.二者都是「三層」。

這個原因是最容易迷惑我們初學者的，一個是UI,BLL,DAL，一個是View，Controller，Model，不都是三層嗎？

雖然都是「三層」（不一定是真的三層，還可以是多層），但是它們的劃分的不一樣。大家可從上面的圖中看出不同。

2.MVC總是伴隨著三層架構。

這個就是我在前面一再強調的，我們一般是在考慮使用（也可以不使用）了三層架構的基礎上再根據具體需求決定是否需要使用MVC，於是我們常說的MVC中總是伴隨著三層架構，所以大家總是會認為MVC就是三層架構，三層架構就是MVC，殊不知，它們二者是一起出現的。

3.都是在分層，即都是在解耦。

前面說它們目的的時候也說了，雖然它們的側重點不同，但是它們的總體目的是一樣的，都是為了解耦，對於初學者而言，是不知道這兩個側重點有何不同的。

大家往往對它們的聯系知道很多，不然也不會混為一談，但是對它們的區別卻知道較少，希望我上面講解的它們兩者之間的區別可以讓大家對它們有些了解，如有寫的不妥的地方，請指教。

三層架構（3-tier application） 通常意義上的三層架構就是將整個業務應用劃分為：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。區分層次的目的即為了「高內聚，低耦合」的思想。

1、表現層（UI）：通俗講就是展現給用戶的界面，即用戶在使用一個系統的時候他的所見所得。

2、業務邏輯層（BLL）：針對具體問題的操作，也可以說是對數據層的操作，對數據業務邏輯處理。

3、數據訪問層（DAL）：該層所做事務直接操作資料庫，針對數據的增添、刪除、修改、更新、查找等。

MVC是 Model-View-Controller，嚴格說這三個加起來以後才是三層架構中的UI層，也就是說，MVC把三層架構中的UI層再度進行了分化，分成了控制器、視圖、實體三個部分，控制器完成頁面邏輯，通過實體來與界面層完成通話；而C層直接與三層中的BLL進行對話。

mvc可以是三層中的一個表現層框架，屬於表現層。三層和mvc可以共存。

三層是基於業務邏輯來分的，而mvc是基於頁面來分的。

MVC主要用於表現層，3層主要用於體系架構，3層一般是表現層、中間層、數據層，其中表現層又可以分成M、V、C，（Model View Controller）模型－視圖－控制器

曾把MVC模式和Web開發中的三層結構的概念混為一談，直到今天才發現一直是我的理解錯誤。MVC模式是GUI界面開發的指導模式，基於表現層分離的思想把程序分為三大部分：Model-View-Controller，呈三角形結構。Model是指數據以及應用程序邏輯，View是指 Model的視圖，也就是用戶界面。這兩者都很好理解，關鍵點在於Controller的角色以及三者之間的關系。在MVC模式中，Controller和View同屬於表現層，通常成對出現。Controller被設計為處理用戶交互的邏輯。一個通常的誤解是認為Controller負責處理View和Model的交互，而實際上View和Model之間是可以直接通信的。由於用戶的交互通常會涉及到Model的改變和View的更新，所以這些可以認為是Controller的副作用。

MVC是表現層的架構，MVC的Model實際上是ViewModel，即供View進行展示的數據。 ViewModel不包含業務邏輯，也不包含數據讀取。

而在N層架構中，一般還會有一個Model層，用來與資料庫的表相對應，也就是所謂ORM中的O.這個Model可能是POCO，也可能是包含一些驗證邏輯的實體類，一般也不包含數據讀取。進行數據讀取的是數據訪問層。而作為UI層的MVC一般不直接操作數據訪問層，中間會有一個業務邏輯層封裝業務邏輯、調用數據訪問層。UI層（Controller）通過業務邏輯層來得到數據（Model），並進行封裝（ViewModel），然後選擇相應的View.

MVC本來是存在於Desktop程序中的，M是指數據模型，V是指用戶界面，C則是控制器。使用MVC的目的是將M和V的實現代碼分離，從而使同一個程序可以使用不同的表現形式。比如一批統計數據你可以分別用柱狀圖、餅圖來表示。C存在的目的則是確保M和V的同步，一旦M改變，V應該同步更新。

MVC如何工作MVC是一個設計模式，它強制性的使應用程序的輸入、處理和輸出分開。使用MVC應用程序被分成三個核心部件：模型、視圖、控制器。它們各自處理自己的任務。

視圖V視圖是用戶看到並與之交互的界面。對老式的Web應用程序來說，視圖就是由HTML元素組成的界面，在新式的Web應用程序中，HTML依舊在視圖中扮演著重要的角色，但一些新的技術已層出不窮，它們包括Macromedia Flash和象XHTML，XML/XSL，WML等一些標識語言和Web services.如何處理應用程序的界面變得越來越有挑戰性。MVC一個大的好處是它能為你的應用程序處理很多不同的視圖。在視圖中其實沒有真正的處理發生，不管這些數據是聯機存儲的還是一個雇員列表，作為視圖來講，它只是作為一種輸出數據並允許用戶操縱的方式。

模型M模型表示企業數據和業務規則。在MVC的三個部件中，模型擁有最多的處理任務。被模型返回的數據是中立的，就是說模型與數據格式無關，這樣一個模型能為多個視圖提供數據。由於應用於模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復性。

控制器C控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求。所以當單擊Web頁面中的超鏈接和發送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求並決定調用哪個模型構件去處理請求，然後再確定用哪個視圖來顯示返回的數據。

模型Model 模型是應用程序的主體部分。模型表示業務數據，或者業務邏輯。 實現具體的業務邏輯、狀態管理的功能。

視圖View 視圖是應用程序中用戶界面相關的部分，是用戶看到並與之交互的界面。 就是與用戶實現交互的頁面，通常實現數據的輸入和輸出功能。

控制器controller 控制器工作就是根據用戶的輸入，控制用戶界面數據顯示和更新model對象狀態。起到控制整個業務流程的作用，實現View層跟Model層的協同工作。

3層架構指：表現層（顯示層） 業務邏輯層 數據訪問層（持久化）如果大家非要「生搬硬套」把它和MVC扯上關系話那我就只能在這里」強扭這個瓜」了即：V 3層架構中」表現層」aspx頁面對應MVC中View（繼承的類不一樣）

C 三層架構中」表現層」的aspx.cs頁面（類）對應MVC中的Controller，理解這一點並不難，大家想一想我們以前寫過的 Redirect，當然它本身就是跳轉了一些鏈接頁面，而MVC中的Controller要做的更爽，它控制並顯示輸出了一個視圖。即然所起到的作用都是對業務流程和顯示信息的控制，只不過是實現手段不同而已。

M 3層架構中業務邏輯層和數據訪問層對應MVC中Model（必定View和Controller已找到「婆家」剩下Model只能是業務邏輯層和數據訪問層了）

為什麼要使用 MVC大部分Web應用程序都是用像ASP，PHP，或者CFML這樣的過程化（自PHP5.0版本後已全面支持面向對象模型）語言來創建的。它們將像資料庫查詢語句這樣的數據層代碼和像HTML這樣的表示層代碼混在一起。經驗比較豐富的開發者會將數據從表示層分離開來，但這通常不是很容易做到的，它需要精心的計劃和不斷的嘗試。MVC從根本上強制性的將它們分開。盡管構造MVC應用程序需要一些額外的工作，但是它給我們帶來的好處是無庸質疑的。

首先，最重要的一點是多個視圖能共享一個模型，現在需要用越來越多的方式來訪問你的應用程序。對此，其中一個解決之道是使用MVC，無論你的用戶想要Flash界面或是 WAP 界面；用一個模型就能處理它們。由於你已經將數據和業務規則從表示層分開，所以你可以最大化的重用你的代碼了。

由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同界面使用。例如，很多數據可能用HTML來表示，但是它們也有可能要用Adobe Flash和WAP來表示。模型也有狀態管理和數據持久性處理的功能，例如，基於會話的購物車和電子商務過程也能被Flash網站或者無線聯網的應用程序所重用。

因為模型是自包含的，並且與控制器和視圖相分離，所以很容易改變你的應用程序的數據層和業務規則。如果你想把你的資料庫從MySQL移植到Oracle，或者改變你的基於RDBMS數據源到LDAP，只需改變你的模型即可。一旦你正確的實現了模型，不管你的數據來自資料庫或是LDAP伺服器，視圖將會正確的顯示它們。由於運用MVC的應用程序的三個部件是相互獨立，改變其中一個不會影響其它兩個，所以依據這種設計思想你能構造良好的松耦合的構件。

對我來說，控制器也提供了一個好處，就是可以使用控制器來聯接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據用戶的需求選擇模型進行處理，然後選擇視圖將處理結果顯示給用戶。

拿一個簡單的登陸模塊說，需求是你輸入一個用戶名、密碼，如果輸入的跟預先定義好的一樣，那麼就進入到正確頁面，如果不一樣，就提示個錯誤信息。

V 這個小小的模塊中，起始的輸入用戶名密碼的頁面跟經過校驗後顯示的頁面就相當於View C 而這里還需要一個controller頁面，就是用於接收輸入進來的用戶名密碼，還有經過校驗後返回的一個flg（此flg就是用於判斷你輸入的是否正確，而跳轉到相應的頁面的）

M 最後還缺一個Model，那麼就是你那個用於校驗的類了，他就是處理你輸入的是否跟預先訂好的一樣不一樣的，之後返回一個flg.這樣就完全實現了邏輯跟頁面的分離，我頁面不管你咋整，反正我就一個顯示，而controller呢也不管你Model咋判斷對不對，反正我給你了用戶名跟密碼，你就得給我整回來一個flg來，而Medol呢，則是反正你敢給我個用戶名跟密碼，我就給你整過去個flg

m 提供數據，數據之間的關系，轉化等。並可以通知視圖和控制器自己哪些地方發生了變化。

v 提供顯示，能根據m的改變來更新自己c 比如視圖做了點擊一個按鈕，會先發給這個視圖的控制器，然後這個控制器來決定做什麼操作（讓模型更新數據，控制視圖改變）

mvc是一個復合模式mv，mc都是觀察者模式m內部的組件組合模式vc之間是策略模式（可以隨時更換不同的控制器）

————————————-

MVC模式是上世紀70年代提出，最初用於Smalltalk平台上的。

MVC是表現模式，是用來向用戶展現的許多組建的一個模式（UI/Presentation Patten）

MVC有三種角色：Model：用來儲存數據的組件（與領域模型概念不同，兩者會相互交叉）

View：從Model中獲取數據進行內容展示的組件。同樣的Model在不同的View下可展示不同的效果。獲取Model的狀態，而不對其進行操作。

Controller：接受並處理用戶指令（操作Model（業務）），選擇一個View進行操作。

MVC概述：協作存在單向引用，例如Model不知道View和Controller的存在。View不知道Controller的存在。這就隔離了表現和數據。View和controller是單向引用。而實際中View和Controller也是有數據交互的。

MVC的重要特點是分離。兩種分離：View和數據（Model）的分離使用不同的View對相同的數據進行展示；分離可視和不可視的組件，能夠對Model進行獨立測試。因為分離了可視組件減少了外部依賴利於測試。（資料庫也是一種外部組件）

View和表現邏輯（Controller）的分離Controller是一個表現邏輯的組件，並非一個業務邏輯組件。MVC可以作為表現模式也可以作為建構模式，意味這Controller也可以是業務邏輯。分離邏輯和具體展示，能夠對邏輯進行獨立測試。

MVC和三層架構MVC與三層架構類似么？

View-UI Layer | Controller-Bussiness Layer | Model-Data Access Layer其實這樣是錯誤的MVC是表現模式（Presentation Pattern）

三層架構是典型的架構模式（Architecture Pattern）

三層架構的分層模式是典型的上下關系，上層依賴於下層。但MVC作為表現模式是不存在上下關系的，而是相互協作關系。即使將MVC當作架構模式，也不是分層模式。MVC和三層架構基本沒有可比性，是應用於不同領域的技術。

Ⅷ javaweb開發中三層架構的一個困惑

網上搜索的,不對我在找 :

java 三層架構ssh

一個spring2.5+hibernate3.2+struts2.0組合框架，使用spring的 IoC來管理應用的 所有bean，包括struts2的 action，充分發揮了spring輕量級框架的 優勢。

摘 要: 針對當前Web應用程序開發面臨的問題，結合目前比較流行的開源框架Spring、Struts和Hibernate，提出了一種開發J2EE Web應用的輕量級解決方案，以幫助開發人員在短期內搭建結構清晰、可復用性好、維護方便的Web應用程序。並且，通過案例具體說明了如何將這一方案應用到實際項目中。
關鍵詞: J2EE MVC Struts Spring Hibernate

大型企業級Web應用系統的開發通常要求有一個良好的軟體架構、便於協作開發和擴展升級，而傳統的開發模式不能很好地滿足這些要求。本文針對當前Web應用程序開發面臨的問題，結合目前比較流行的開源框架SSH（Spring、Struts、Hibernate)，提出一種開發J2EE 企業級Web應用的輕量級解決方案，並通過案例具體說明如何將這一方案應用到實際項目中。
1 框架技術
著名的軟體大師Ralph Johnson對框架(Framework)進行了如下的定義： 框架是整個系統或系統的一部分的可重用設計，由一組抽象的類及其實例間的相互作用方式組成[1] 。
框架一般具有即插即用的可重用性、成熟的穩定性以及良好的團隊協作性。J2EE復雜的多層結構決定了大型的J2EE項目需要運用框架和設計模式來控制軟體質量。目前，市場上出現了一些商業的、開源的基於J2EE的應用框架，其中主流的框架技術有：基於MVC模式的Struts框架和基於IoC模式的 Spring框架以及對象/關系映射框架Hibernate等。
1.1 表示層框架Struts
Struts是一個在JSP Model2基礎上實現的MVC框架，主要分為模型(Model)、視圖(Viewer)和控制器(Controller)三部分，其主要的設計理念是通過控制器將表現邏輯和業務邏輯解耦，以提高系統的可維護性、可擴展性和可重用性[2] 。Struts框架的體系結構如圖1所示。

下面就圖1所示的體系結構圖分析Struts框架中的MVC組件。
（1）視圖：視圖部分主要由JSP頁面組成，其中沒有流程邏輯、業務邏輯和模型信息，只有標記。Struts自身包含了一組標記庫(TagLib)，這也是Struts的精華之一，靈活運用它們可以簡化JSP頁面的代碼，提高開發效率。
（2）控制器：Struts中的Controller主要是其自身提供的ActionServlet。ActionServlet接收所有來自客戶端的請求並根據配置文件(struts-config.xml)中的定義將控制轉移到適當的Action對象。
（3）模型：Struts沒有定義具體Model層的實現，Model層通常是和業務邏輯緊密相關的，有持續化的要求。目前在商業領域和開源世界，都有一些優秀的工具可以為Model層的開發提供便利。
1.2 業務邏輯層框架Spring
Spring是一個解決了許多J2EE開發中常見問題並能夠替代EJB技術的強大的輕量級框架。這里所說的輕量級指的是 Spring框架本身，而不是指Spring只能用於輕量級的應用開發。Spring的輕盈體現在其框架本身的基礎結構以及對其他應用工具的支持和裝配能力。與EJB這種龐然大物相比，Spring可使程序研發人員把各個技術層次之間的風險降低。
Spring框架的核心是控制翻轉IoC(Inversion of Control)/依賴注入DI(Dependence Injection)機制。IoC是指由容器中控制組件之間的關系（這里，容器是指為組件提供特定服務和技術支持的一個標准化的運行時的環境）而非傳統實現中由程序代碼直接操控，這種將控制權由程序代碼到外部容器的轉移，稱為「翻轉」[3] 。DI是對IoC更形象的解釋，即由容器在運行期間動態地將依賴關系(如構造參數、構造對象或介面)注入到組件之中[3] 。 Spring採用設值注入(使用Setter方法實現依賴)和構造子注入(在構造方法中實現依賴)的機制，通過配置文件管理組建的協作對象，創建可以構造組件的IoC容器。這樣，不需要編寫工廠模式、單例模式或者其他構造的方法，就可以通過容器直接獲取所需的業務組件。Spring框架的結構如圖2所示。

Spring框架由七個定義明確的模塊組成，且每個模塊或組件都可以單獨存在，或者與其他一個或多個模塊聯合實現。Spring Core Container是一個用來管理業務組件的IoC容器，是Spring應用的核心；Spring DAO和Spring ORM不僅提供數據訪問的抽象模塊，還集成了對Hibernate、JDO和iBatis等流行的對象關系映射框架的支持模塊，並且提供了緩沖連接池、事務處理等重要的服務功能，保證了系統的性能和數據的完整性；Sprnig Web模塊提供了Web應用的一些抽象封裝，可以將Struts、Webwork等Web框架與Spring整合成為適用於自己的解決方案。
Spring框架可以成為企業級應用程序一站式的解決方案，同時它也是模塊化的框架，允許開發人員自由地挑選適合自己應用的模塊進行開發。Spring框架式是一個松耦合的框架，框架的部分耦合度被設計為最小，在各個層次上具體選用哪個框架取決於開發者的需要。
1.3 數據持久層框架Hibernate
O/R mapping技術是為了解決關系型資料庫和面向對象的程序設計之間不匹配的矛盾而產生的。Hibernate是目前最為流行的O/R mapping框架，它在關系型資料庫和Java對象之間做了一個自動映射，使得程序員可以以非常簡單的方式實現對資料庫的操作。Hibernate工作原理如圖3所示。

Hibernate通過對JDBC的封裝，向程序員屏蔽了底層的資料庫操作，使程序員專注於OO程序的開發，有助於提高開發效率。程序員訪問資料庫所需要做的就是為持久化對象編制xml映射文件[4] 。
底層資料庫的改變只需要簡單地更改初始化配置文件(hibernate.cfg.xml或者hibernate.properties)即可，不會對應用程序產生影響。
Hibernate有自己的面向對象的查詢語言HQL，HQL功能強大，支持目前大部分主流的資料庫，如Oracle、DB2、MySQL、 Microsoft SQL Server等，是目前應用最廣泛的O/R映射工具。Hibernate為快速開發應用程序提供了底層的支持。
2 基於SSH組合框架的Web應用模型設計與實現
2.1 集成SSH的新型J2EE框架
前面分析了基於J2EE的三種框架技術，下面通過集成以上三種框架技術來對傳統的J2EE Web開發模型加以改進，以形成一種新的、輕量型的J2EE架構。
集成SSH框架 的系統框架圖 如圖4所示，系統從職責上分為四層：表示層、業務邏輯層、數據持久層和域模塊層。其中使用Struts作為系統的整體基礎架構，負責MVC的分離，在 Struts框架的模型部分，利用Hibernate框架對持久層提供支持，業務層用Spring支持。具體做法是：用面向對象的分析方法根據需求提出一些模型，將這些模型實現為基本的Java對象，然後編寫基本的DAO介面，並給出Hibernate的DAO實現，採用Hibernate架構實現的 DAO類來實現Java類與資料庫之間的轉換和訪問，最後由Spring完成業務邏輯。

系統的基本業務流程是：在表示層中，首先通過JSP頁面實現交互界面，負責傳送請求(Request)和接收響應(Response)，然後Struts根據配置文件 (struts-config.xml)將ActionServlet接收到的Request委派給相應的Action處理。在業務層中，管理服務組件的 Spring IoC容器負責向Action提供業務模型(Model)組件和該組件的協作對象數據處理(DAO)組件完成業務邏輯，並提供事務處理、緩沖池等容器組件以提升系統性能和保證數據的完整性。而在持久層中，則依賴於Hibernate的對象化映射和資料庫交互，處理DAO組件請求的數據，並返回處理結果。
採用上述開發模型，不僅實現了視圖、控制器與模型的徹底分離，而且還實現了業務邏輯層與持久層的分離。這樣無論前端如何變化，模型層只需很少的改動，並且資料庫的變化也不會對前端有所影響，大大提高了系統的可復用性。而且由於不同層之間耦合度小，有利於團隊成員並行工作，大大提高了開發效率。
2.2 基於SSH框架 的Web應用系統的實現
下面將通過一個實際的系統來展示如何進行基於SSH框架 的Web應用開發。該系統是為某通信公司運營部開發的一個問答式系統，功能類似於網路知道和新浪愛問。由於系統的模塊較多，下面就以一個用戶管理模塊為例來說明系統的開發實現過程，並將按照數據持久層、業務邏輯層、表示層的順序說明系統構建過程。
（1）數據持久層
數據持久層由Java對象持久化類和數據訪問對象(DAO)組成。每個資料庫表都對應著一個持久化對象，這樣就給予了開發者使用OO思想設計和開發的便利，同時也屏蔽了具體的資料庫和具體的數據表、欄位，消除了對資料庫操作的硬編碼在重用性上的弊端。用戶信息表的部分結構如表1所示。

Hibernate通過映射(Mapping)文件將對象(Object)與關系型數據(Relational)相關聯，因此需要編寫和資料庫表相對應的Java持久化類以及對應的映射文件。有了Java持久化類後就可以在此基礎上實現數據訪問類。在Spring框架中，數據訪問類可以從輔助類 HibernateDaoSupport繼承，這極大地方便了Hibernate框架在Spring中的使用，相應的部分代碼如下：
public class UserDao
extends HibernateDaoSupport {
public int add(User user) {
return Integer.ParseInt(this.getHibernateTemplate().save(user).toString());
}
public List findAll() {
return this.getHibernateTemplate().loadAll(User.class);
}
}
具體的Hibernate數據源、session工廠、事務管理、緩沖連接池等功能都由業務層的Spring容器提供。
（2）業務邏輯層
業務邏輯層由Spring框架支持，提供了處理業務邏輯的服務組件。開發者需要對業務對象建模，抽象出業務模型並封裝在Model組件中。由於數據持久層實現了Java持久化類並且封裝了數據訪問對象(DAO)，因此可以在Model組件中方便地調用DAO組件來存取數據。Spring的IoC容器負責統一管理Model組件和DAO組件以及Spring所提供的事務處理、緩沖連接池等服務組件。
在用戶管理模塊中，通過業務建模創建了用戶模型UserService類，封裝了對用戶的許可權管理以及積分管理等功能。UserService類通過調用數據訪問類UserDao實現對用戶數據的操作。這些組件的關系將通過配置Spring框架的applicationContext.xml聯系起來，配置文件的主要內容如下：



（3）表示層
表示層結合JSP和Struts的TagLib庫處理顯示功能，利用ActionServlet將請求(*.do)映射到相應的Action，並由Action調用業務邏輯的服務組件，然後根據處理結果跳轉到Forword對象指定的響應頁面。
業務流程的部署由struts-config.xml完成。下面以一個顯示所有用戶信息的請求(ListUser.do)為例來說明配置文件的使用。


基於J2EE的Web應用以其層次性、平台無關性的優勢已經逐漸成為了電子商務、電子政務主要的解決方案。本文針對傳統的J2EE Web應用開發的弊端，提出了一種利用輕量級框架來快速搭建Web應用的解決方案，並且通過其在實際項目中的應用，證明了採用此方案可以幫助開發人員在短時間內建立結構清晰、可重用性好、維護擴展方便的Web應用程序。
參考文獻
[1] GAMMA E, HELM R, JOHNSON R, et al. Design patterns:Elements of reusable object-oriented software[M]. Addison Wesley, 1994.
[2] 孫衛琴.精通Struts:基於MVC的Java Web設計與開發[M]. 北京：電子工業出版社,2004.
[3] JOHNSON R, HOELLER J, ARENDSEN A, et al. Java/J2EE application framework reference document. V1.1.
2004.
[4] 徐長盛,戴超.一種快速開發Web應用程序方法的研究[J]. 計算機工程與設計,2004,(12):2237-2239.
[5] 夏昕,曹曉鋼,唐勇.深入淺出Hibernate[M]. 北京：電子工業出版社,2005.
[6] JOHNSON R.Expert one-on-one J2EE design and development[M]. 魏海萍譯.北京：電子工業出版社,2003.

在用ssh 開發web應用時，需要對生成的 各個類文件進行組織，下面就對一個可行的 目錄方案進行介紹：

譬如應用中有一個用戶管理模塊，則在公共包下建立一個user包，如該公共包可以為com.simon.oa，

在user包下包括如下子包

1、controler包

該包放置各種struts的 action。

2、包

該包放置各類（data access object），也就是放置對資料庫訪問的 實現類，在用myeclipse中的 「Hibernate Reverse Engineering」進行反向操作時在某一個目錄中就會生成對應某個表的 DAO，生成後可將該DAO拖到包中。在某些應用中將DAO作為介面，在該介面中包括所有對資料庫的 操作方法，然後在包建立一個hibernate包，在hibernate包中放置對DAO介面的 實現，譬如：UserDAO介面有一個實現類為UserDaoImpl，將該類放置到hibernate包中，實際的 開發傾向於後一種方式，因為對這個DAO介面可以實現spring的 IoC操作。(不知道myeclipse對此是怎麼考慮的 ，這個問題讓我糾纏了很久，誤將DAO理解成一個能夠進行實際操作的 類，而不是一個介面，以後開發要注意 )

3、model包

該包中放置hibernate反向工程生成的 bean和該bean對應的 .hbm.xml文件。

4、service包

該包放置業務操作類，譬如用戶服務類，一般情況將該用戶操作類提取一個介面，然後在service包下生成一個impl包，在impl包中才放置用戶操作介面的 實現類。該用戶介面實現類中調用DAO介面對資料庫進行操作，而調用該實現類的 方法在struts的 action中。

5、vo包（value object）

vo包中的 中包括struts中使用的 POJO及actionform等信息。

VO: Value Object
DTO: Data Transfer Object
個人理解VO和DTO是類似的 東西，原則上VO和DTO只有Public Fields，主要用於進程之間數據傳遞的 問題，VO和DTO不會傳遞到表示層，在業務層就會被吸收。但看到很多人在建立VO和DTO時，也含有Setter,Getter屬性和一些其它的 輔助方法，這也無可厚非，我自己也不能確定這對不對。