❶ MVC三層框架概述
MVC（模型Model-視圖View-控制器Controller）是一種設計模式，
MVC。V即View.是視圖的意思。C即Controller.是控制器的意思。而M即Model，是模型的意思。這三個里.最不容易理解的應該是Model.就是什麼是Model，而為什麼叫Model。我先不說為什麼叫Model，先解釋Controller。
Controller是控制器的意思，所謂控制器，就是將用戶請求轉發給模型層，經過處理後把結果返回到界面層展現的一個中間層，那麼Controller到底管什麼工作呢？先不說.先來看下在Java Web中這三個層一般的定義，一般在Java Web里，JSP充當V，Servlet充當C,JavaBean充當M，這里的Servlet管什麼工作呢？接受輸入，轉到Model層去處理，處理結果保存後轉發到JSP，然後展現數據。所以它的功能就是控制器的基本功能，它就管轉發，在V和M之間轉來轉去。
再來說說M，即Model，在Java Web里說的是JavaBean，我認識的很多人都把JavaBean誤認為是實體類，其實JavaBean有比實體類更豐富的定義，在JavaBean中除了其屬性和欄位，還可以有行為及其事件，JavaBean可以理解為普通Java對象。Java普通對象，就是符合Java規范的所有對象，這和實體類完全是兩回事。所以，我認為在MVC中。業務邏輯和數據訪問應該放在Model層，也就是V負責展示數據，Controler除了轉發不做業務邏輯。真正的邏輯事務，數據訪問，甚至演算法都放到Model去。
MVC沒有把業務的邏輯訪問看成兩個層，這是採用三層架構或MVC搭建程序最主要的區別。當然了。在三層中也提到了Model，但是三層架構中Model的概念與MVC中Model的概念是不一樣的，「三層」中典型的Model層是已實體類構成的，而MVC里，則是由業務邏輯與訪問數據組成的。
❷ java設計問題什麼是MVC設計模式和三層架構有什麼區別，它們是不是一個意思
當然不是一個意思了，基於Java 的Web 應用系統採用MVC 架構模式，即model（模型）、view（視圖）、control（控制）分離設計；這是目前WEB 應用服務系統的主流設計方向。
Model：即處理業務邏輯的模塊，每一種處理一個模塊；
View：負責頁面顯示，顯示MODEL 處理結果給用戶，主要實現數據到頁面轉換過程；
Control：負責每個請求的分發，把FORM 數據傳遞給MODEL 處理，把處理結果的數據傳遞給VIEW 顯示。
❸ 什麼是MVC(三層架構)
MVC是一個設計模式，它強制性的使應用程序的輸入、處理和輸出分開。使用MVC應用程序被分成三個核心部件：模型、視圖、控制器。它們各自處理自己的任務。
視圖視圖是用戶看到並與之交互的界面。對老式的Web應用程序來說，視圖就是由HTML元素組成的界面，在新式的Web應用程序中，HTML依舊在視圖中扮演著重要的角色，但一些新的技術已層出不窮，它們包括MacromediaFlash和象XHTML，XML/XSL，WML等一些標識語言和Webservices.
模型模型表示企業數據和業務規則。在MVC的三個部件中，模型擁有最多的處理任務。例如它可能用象EJBs和ColdFusionComponents這樣的構件對象來處理資料庫。被模型返回的數據是中立的，就是說模型與數據格式無關，這樣一個模型能為多個視圖提供數據。由於應用於模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復性。
控制器控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求。所以當單擊Web頁面中的超鏈接和發送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求並決定調用哪個模型構件去處理請求，然後用確定用哪個視圖來顯示模型處理返回的數據。
現在我們總結ＭVC的處理過程，首先控制器接收用戶的請求，並決定應該調用哪個模型來進行處理，然後模型用業務邏輯來處理用戶的請求並返回數據，最後控制器用相應的視圖格式化模型返回的數據，並通過表示層呈現給用戶。
大部分Web應用程序都是用像ASP，PHP，或者CFML這樣的過程化語言來創建的。它們將像資料庫查詢語句這樣的數據層代碼和像HTML這樣的表示層代碼混在一起。經驗比較豐富的開發者會將數據從表示層分離開來，但這通常不是很容易做到的，它需要精心的計劃和不斷的嘗試。MVC從根本上強制性的將它們分開。盡管構造MVC應用程序需要一些額外的工作，但是它給我們帶來的好處是無庸質疑的。
首先，最重要的一點是多個視圖能共享一個模型，正如我所提及的，現在需要用越來越多的方式來訪問你的應用程序。對此，其中一個解決之道是使用MVC，無論你的用戶想要Flash界面或是 WAP 界面；用一個模型就能處理它們。由於你已經將數據和業務規則從表示層分開，所以你可以最大化的重用你的代碼了。
由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同界面使用。例如，很多數據可能用HTML來表示，但是它們也有可能要用Macromedia Flash和WAP來表示。模型也有狀態管理和數據持久性處理的功能，例如，基於會話的購物車和電子商務過程也能被Flash網站或者無線聯網的應用程序所重用。
因為模型是自包含的，並且與控制器和視圖相分離，所以很容易改變你的應用程序的數據層和業務規則。如果你想把你的資料庫從MySQL移植到Oracle，或者改變你的基於RDBMS數據源到LDAP，只需改變你的模型即可。一旦你正確的實現了模型，不管你的數據來自資料庫或是LDAP伺服器，視圖將會正確的顯示它們。由於運用MVC的應用程序的三個部件是相互對立，改變其中一個不會影響其它兩個，所以依據這種設計思想你能構造良好的松偶合的構件。
對我來說，控制器的也提供了一個好處，就是可以使用控制器來聯接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據用戶的需求選擇模型進行處理，然後選擇視圖將處理結果顯示給用戶。
MVC的缺點MVC的缺點是由於它沒有明確的定義，所以完全理解MVC並不是很容易。使用MVC需要精心的計劃，由於它的內部原理比較復雜，所以需要花費一些時間去思考。
根據我個人經驗，由於我們將一個應用程序分成了三個部件，所以使用MVC同時也意味著你將要管理比以前更多的文件，這一點是顯而易見的。這樣好像我們的工作量增加了，但是請記住這比起它所能帶給我們的好處是不值一提。
MVC並不適合小型甚至中等規模的應用程序，花費大量時間將MVC應用到規模並不是很大的應用程序通常會得不償失。
MVC是一條創建軟體的好途徑
MVC設計模式是一個很好創建軟體的途徑，它所提倡的一些原則，像內容和顯示互相分離可能比較好理解。但是如果你要隔離模型、視圖和控制器的構件，你可能需要重新思考你的應用程序，尤其是應用程序的構架方面。如果你肯接受MVC，並且有能力應付它所帶來的額外的工作和復雜性，MVC將會使你的軟體在健壯性，代碼重用和結構方面上一個新的台階。
Java開發Web Application有幾種符合MVC設計模式的開發方式。
1:Jsp+Servlet+JavaBean(EJB)
2:Jsp+JavaBean(Controller)+JavaBean(EJB)(Model)
3:TDK(Turbine，Velocity...)
4:Xsp5:Jsp+Struts+JavaBean(EJB)附：三層架構即「表現層」，「業務層」，「持久化層」。表現層實現的代表作品是Struts框架，業務層實現的代表作品是Spring，持久層實現的代表作品是Hibernate。
舉個例子。
持久層從持久庫中取出-10。
業務層按照一定的邏輯（這里我們舉例取溫度的邏輯）翻譯成-10攝氏度。
表示層顯現給用戶「哎呀，今天好冷！」。
❹ 三層架構和mvc模式是什麼技術
三層架構是一個分層式的軟體體系架構設計，它可適用於任何一個項目。三層架構將整個項目劃分為：表現層(ui)、業務邏輯層(bll)、數據訪問層(dal)。
mvc是一個設計模式，它是根據項目的具體需求來決定是否適用於該項目。mvc可分為：model模型層、view視圖層、controller控制層;
總結：在java
web開發中，mvc框架充當了ui層和業務邏輯層的適配器的作用。mvc框架實現了ui層和業務邏輯層最大程度的分離。
❺ java中 MVC 三層架構
MVC模式是"Model-View-Controller"的縮寫，中文翻譯為"模式-視圖-控制器"。MVC應用程序總是由這三個部分組成。Event(事件)導致Controller改變Model或View，或者同時改變兩者。只要Controller改變了Models的數據或者屬性，所有依賴的View都會自動更新。類似的，只要Controller改變了View，View會從潛在的Model中獲取數據來刷新自己。MVC模式最早是smalltalk語言研究團提出的，應用於用戶交互應用程序中。smalltalk語言和java語言有很多相似性,都是面向對象語言，很自然的SUN在petstore(寵物店)事例應用程序中就推薦MVC模式作為開發Web應用的架構模式。MVC模式是一種架構模式，其實需要其他模式協作完成。在J2EE模式目錄中，通常採用service to worker模式實現，而service to worker模式可由集中控制器模式，派遣器模式和Page Helper模式組成。而Struts只實現了MVC的View和Controller兩個部分，Model部分需要開發者自己來實現，Struts提供了抽象類Action使開發者能將Model應用於Struts框架中。
MVC模式是一個復雜的架構模式，其實現也顯得非常復雜。但是，我們已經終結出了很多可靠的設計模式，多種設計模式結合在一起，使MVC模式的實現變得相對簡單易行。Views可以看作一棵樹，顯然可以用Composite Pattern來實現。Views和Models之間的關系可以用Observer Pattern體現。Controller控制Views的顯示，可以用Strategy Pattern實現。Model通常是一個調停者，可採用Mediator Pattern來實現。
現在讓我們來了解一下MVC三個部分在J2EE架構中處於什麼位置，這樣有助於我們理解MVC模式的實現。MVC與J2EE架構的對應關系是:View處於Web Tier或者說是Client Tier，通常是JSP/Servlet，即頁面顯示部分。Controller也處於Web Tier，通常用Servlet來實現，即頁面顯示的邏輯部分實現。Model處於Middle Tier，通常用服務端的javaBean或者EJB實現，即業務邏輯部分的實現。
一、MVC設計思想
MVC英文即Model-View-Controller，即把一個應用的輸入、處理、輸出流程按照Model、View、Controller的方式進行分離，這樣一個應用被分成三個層——模型層、視圖層、控制層。
視圖(View)代表用戶交互界面，對於Web應用來說，可以概括為HTML界面，但有可能為XHTML、XML和Applet。隨著應用的復雜性和規模性，界面的處理也變得具有挑戰性。一個應用可能有很多不同的視圖，MVC設計模式對於視圖的處理僅限於視圖上數據的採集和處理，以及用戶的請求，而不包括在視圖上的業務流程的處理。業務流程的處理交予模型(Model)處理。比如一個訂單的視圖只接受來自模型的數據並顯示給用戶，以及將用戶界面的輸入數據和請求傳遞給控制和模型。
模型(Model)：就是業務流程/狀態的處理以及業務規則的制定。業務流程的處理過程對其它層來說是黑箱操作，模型接受視圖請求的數據，並返回最終的處理結果。業務模型的設計可以說是MVC最主要的核心。目前流行的EJB模型就是一個典型的應用例子，它從應用技術實現的角度對模型做了進一步的劃分，以便充分利用現有的組件，但它不能作為應用設計模型的框架。它僅僅告訴你按這種模型設計就可以利用某些技術組件，從而減少了技術上的困難。對一個開發者來說，就可以專注於業務模型的設計。MVC設計模式告訴我們，把應用的模型按一定的規則抽取出來，抽取的層次很重要，這也是判斷開發人員是否優秀的設計依據。抽象與具體不能隔得太遠，也不能太近。MVC並沒有提供模型的設計方法，而只告訴你應該組織管理這些模型，以便於模型的重構和提高重用性。我們可以用對象編程來做比喻，MVC定義了一個頂級類，告訴它的子類你只能做這些，但沒法限制你能做這些。這點對編程的開發人員非常重要。
業務模型還有一個很重要的模型那就是數據模型。數據模型主要指實體對象的數據 保存（持續化）。比如將一張訂單保存到資料庫，從資料庫獲取訂單。我們可以將這個模型單獨列出，所有有關資料庫的操作只限制在該模型中。
控制(Controller)可以理解為從用戶接收請求, 將模型與視圖匹配在一起，共同完成用戶的請求。劃分控制層的作用也很明顯，它清楚地告訴你，它就是一個分發器，選擇什麼樣的模型，選擇什麼樣的視圖，可以完成什麼樣的用戶請求。控制層並不做任何的數據處理。例如，用戶點擊一個連接，控制層接受請求後, 並不處理業務信息，它只把用戶的信息傳遞給模型，告訴模型做什麼，選擇符合要求的視圖返回給用戶。因此，一個模型可能對應多個視圖，一個視圖可能對應多個模型。
模型、視圖與控制器的分離，使得一個模型可以具有多個顯示視圖。如果用戶通過某個視圖的控制器改變了模型的數據，所有其它依賴於這些數據的視圖都應反映到這些變化。因此，無論何時發生了何種數據變化，控制器都會將變化通知所有的視圖，導致顯示的更新。這實際上是一種模型的變化-傳播機制。模型、視圖、控制器三者之間的關系和各自的主要功能，如圖1所示。
二、MVC設計模式的實現
ASP.NET提供了一個很好的實現這種經典設計模式的類似環境。開發者通過在ASPX頁面中開發用戶介面來實現視圖；控制器的功能在邏輯功能代碼(.cs)中實現；模型通常對應應用系統的業務部分。在ASP.NET中實現這種設計而提供的一個多層系統，較經典的ASP結構實現的系統來說有明顯的優點。將用戶顯示（視圖）從動作（控制器）中分離出來,提高了代碼的重用性。將數據（模型）從對其操作的動作（控制器）分離出來可以讓你設計一個與後台存儲數據無關的系統。就MVC結構的本質而言，它是一種解決耦合系統問題的方法。
2.1 視圖
視圖是模型的表示，它提供用戶交互界面。使用多個包含單顯示頁面的用戶部件，復雜的Web頁面可以展示來自多個數據源的內容，並且網頁人員，美工能獨自參與這些Web頁面的開發和維護。
在ASP.NET下，視圖的實現很簡單。可以像開發WINDOWS界面一樣直接在集成開發環境下通過拖動控制項來完成頁面開發本。本文中介紹每一個頁面都採用復合視圖的形式即：一個頁面由多個子視圖(用戶部件)組成；子視圖可以是最簡單HTML 控制項、伺服器控制項或多個控制項嵌套構而成的Web自定義控制項。頁面都由模板定義，模板定義了頁面的布局，用戶部件的標簽和數目，用戶指定一個模板，平台根據這些信息自動創建頁面。針對靜態的模板內容，如頁面上的站點導航，菜單，友好鏈接，這些使用預設的模板內容配置；針對動態的模板內容(主要是業務內容)，由於用戶的請求不同，只能使用後期綁定，並且針對用戶的不同，用戶部件的顯示內容進行過濾。使用由用戶部件根據模板配置組成的組合頁面，它增強了可重用性，並原型化了站點的布局。
視圖部分大致處理流程如下：首先，頁面模板定義了頁面的布局；頁面配置文件定義視圖標簽的具體內容（用戶部件）；然後，由頁面布局策略類初始化並載入頁面；每個用戶部件根據它自己的配置進行初始化，載入校驗器並設置參數，以及事件的委託等；用戶提交後，通過了表示層的校驗，用戶部件把數據自動提交給業務實體即模型。
這一部分主要定義了WEB頁面基類PageBase；頁面布局策略類PageLayout，完成頁面布局，用於載入用戶部件到頁面；用戶部件基類UserControlBase即用戶部件框架，用於動態載入檢驗部件，以及實現用戶部件的個性化。為了實現WEB應用的靈活性，視圖部分也用到了許多配置文件例如：置文件有模板配置、頁面配置、路徑配置、驗證配置等。
2.2 控制器
為了能夠控制和協調每個用戶跨越多個請求的處理，控制機制應該以集中的方式進行管理。因此，為了達到集中管理的目的引入了控制器。應用程序的控制器集中從客戶端接收請求（典型情況下是一個運行瀏覽器的用戶），決定執行什麼商業邏輯功能，然後將產生下一步用戶界面的責任委派給一個適當的視圖組件。
用控制器提供一個控制和處理請求的集中入口點，它負責接收、截取並處理用戶請求；並將請求委託給分發者類，根據當前狀態和業務操作的結果決定向客戶呈現的視圖。在這一部分主要定義了HttpReqDispatcher(分發者類)、HttpCapture(請求捕獲者類)、Controller(控制器類)等，它們相互配合來完成控制器的功能。請求捕獲者類捕獲HTTP請求並轉發給控制器類。控制器類是系統中處理所有請求的最初入口點。控制器完成一些必要的處理後把請求委託給分發者類；分發者類分發者負責視圖的管理和導航，它管理將選擇哪個視圖提供給用戶，並提供給分發資源控制。在這一部分分別採用了分發者、策略、工廠方法、適配器等設計模式。
為了使請求捕獲者類自動捕獲用戶請求並進行處理，ASP.NET 提供低級別的請求/響應 API，使開發人員能夠使用 .NET 框架類為傳入的 HTTP 請求提供服務。為此，必須創作支持 System.Web.IHTTPHandler 介面和實現 ProcessRequest() 方法的類即：請求捕獲者類，並在web.config 的 ＜httphandlers＞ 節中添加類。ASP.NET 收到的每個傳入 HTTP 請求最終由實現 IHTTPHandler 的類的特定實例來處理。IHttpHandlerFactory 提供了處理 IHttpHandler 實例 URL 請求的實際解析的結構。HTTP 處理程序和工廠在 ASP.NET 配置中聲明為 web.config 文件的一部分。ASP.NET 定義了一個 ＜httphandlers＞ 配置節，在其中可以添加和移除處理程序和工廠。子目錄繼承 HttpHandlerFactory 和 HttpHandler 的設置。 HTTP 處理程序和工廠是 ASP.NET 頁框架的主體。工廠將每個請求分配給一個處理程序，後者處理該請求。 例如，在全局 machine.config 文件中，ASP.NET 將所有對 ASPx 文件的請求映射到 HttpCapture類：
＜httphandlers＞
...
...
＜/httphandlers＞
2.3 模型
MVC系統中的模型從概念上可以分為兩類――系統的內部狀態和改變系統狀態的動作。模型是你所有的商業邏輯代碼片段所在。本文為模型提供了業務實體對象和業務處理對象：所有的業務處理對象都是從ProcessBase類派生的子類。業務處理對象封裝了具體的處理邏輯，調用業務邏輯模型，並且把響應提交到合適的視圖組件以產生響應。業務實體對象可以通過定義屬性描述客戶端表單數據。所有業務實體對象都EntityBase派生子類對象，業務處理對象可以直接對它進行讀寫，而不再需要和request、response對象進行數據交互。通過業務實體對象實現了對視圖和模型之間交互的支持。實現時把"做什麼"（業務處理）和"如何做"（業務實體）分離。這樣可以實現業務邏輯的重用。由於各個應用的具體業務是不同的，這里不再列舉其具體代碼實例。
三、MVC設計模式的擴展
通過在ASP.NET中的MVC模式編寫的，具有極其良好的可擴展性。它可以輕松實現以下功能：
①實現一個模型的多個視圖；
②採用多個控制器；
③當模型改變時，所有視圖將自動刷新；
④所有的控制器將相互獨立工作。
這就是MVC模式的好處，只需在以前的程序上稍作修改或增加新的類，即可輕松增加許多程序功能。以前開發的許多類可以重用，而程序結構根本不再需要改變，各類之間相互獨立，便於團體開發，提高開發效率。下面討論如何實現一個模型、兩個視圖和一個控制器的程序。其中模型類及視圖類根本不需要改變，與前面的完全一樣，這就是面向對象編程的好處。對於控制器中的類，只需要增加另一個視圖，並與模型發生關聯即可。該模式下視圖、控制器、模型三者之間的示意圖如圖2所示。
同樣也可以實現其它形式的MVC例如：一個模型、兩個視圖和兩個控制器。從上面可以看出，通過MVC模式實現的應用程序具有極其良好的可擴展性，是ASP.NET面向對象編程的未來方向。
四、MVC的優點
大部分用過程語言比如ASP、PHP開發出來的Web應用，初始的開發模板就是混合層的數據編程。例如，直接向資料庫發送請求並用HTML顯示,開發速度往往比較快,但由於數據頁面的分離不是很直接,因而很難體現出業務模型的樣子或者模型的重用性。產品設計彈性力度很小，很難滿足用戶的變化性需求。MVC要求對應用分層，雖然要花費額外的工作，但產品的結構清晰，產品的應用通過模型可以得到更好地體現。
首先，最重要的是應該有多個視圖對應一個模型的能力。在目前用戶需求的快速變化下，可能有多種方式訪問應用的要求。例如，訂單模型可能有本系統的訂單，也有網上訂單，或者其他系統的訂單，但對於訂單的處理都是一樣，也就是說訂單的處理是一致的。按MVC設計模式，一個訂單模型以及多個視圖即可解決問題。這樣減少了代碼的復制，即減少了代碼的維護量，一旦模型發生改變，也易於維護。 其次，由於模型返回的數據不帶任何顯示格式，因而這些模型也可直接應用於介面的使用。
再次，由於一個應用被分離為三層，因此有時改變其中的一層就能滿足應用的改變。一個應用的業務流程或者業務規則的改變只需改動MVC的模型層。
控制層的概念也很有效，由於它把不同的模型和不同的視圖組合在一起完成不同的請求，因此，控制層可以說是包含了用戶請求許可權的概念。
最後，它還有利於軟體工程化管理。由於不同的層各司其職，每一層不同的應用具有某些相同的特徵，有利於通過工程化、工具化產生管理程序代碼。
五、MVC的不足
MVC的不足體現在以下幾個方面：
（1）增加了系統結構和實現的復雜性。對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的復雜性，並可能產生過多的更新操作，降低運行效率。
（2）視圖與控制器間的過於緊密的連接。視圖與控制器是相互分離，但確實聯系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。
（3）視圖對模型數據的低效率訪問。依據模型操作介面的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。
（4） 目前，一般高級的界面工具或構造器不支持MVC模式。改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，從而造成使用MVC的困難。
❻ 請問JAVA三層架構、持久層、業務層、表現層都該怎麼理解和MVC三層模型有什麼區別
希望還有人關注這個問題。
我們常常提到java EE的三層或者四層結構。
四層架構：
展示層（web層）、業務邏輯層、數據訪問層、信息資源層
四層架構在是開發企業應用時使用的非常經典的劃分模式。
web層負責前端展示和用戶請求的處理。mvc是一個設計模式，主要用戶構建用戶界面，目的是把展示邏輯和邏輯分離。web層通常會使用MVC模式進行構建，經常使用的mvc框架包括spring mvc，struts等，都是在web層或者展示層使用的。
業務邏輯層一般應用中會有一層service抽象，實現核心業務邏輯，事務控制也在這一層實現。
數據訪問層也即層，重點負責資料庫訪問，完成持久化功能。
信息資源層主要服務資源的存儲。
所以mvc和四層（三層）結構有關系，四層架構是應用的體系（分層）結構，描述了整個應用的一個完整的劃分，而mvc是一個設計模式，通常會用於四層架構的展示層的構建上。希望我能講清楚。
❼ java mvc的三層架構是什麼
持久層用來固化數據，如常說的DAO層，操作資料庫將數據入庫業務層用來實現整體的業務邏輯如前台獲得了數據，邏輯層去解析這些數據，效驗這些數據等操作表現層很好解釋你現在看到的網頁一些界面都屬於表現層的東西可以用一些Html，jsp，Swing來
實現至於mvc么對應的是model（模型）view（視圖）Controller（控制）在javaweb中就很好理解了再XX系統中，前台頁面屬於
view貫穿前台後台持久層的一套模型就是model（EJB，Spring來實現）而連接前台後台進行邏輯操作的就是
Controller（Struts來實現）這是最簡單的說法懂嗎？不懂說明真心菜，如果你真心想學習java可以加我們群來學習，群里每天都有分享課哦免費的視頻資料一堆的。但是不是想學的就不要來了，要的加入23-129-41-89，我們喜歡java對它有獨特的見解和學習方式。但交流是促進技術的最好方式。
❽ Java中的mvc和三層結構究竟是什麼關系
一件事，要知其然往往很簡單，要知其所以然通常不是那麼容易，就如最近重新鞏固spring的過程中，就覺得還有許多問題其實並不是十分明了。
屈指一算，手頭上做過的正式項目也有了四五六七個了，不管用的資料庫和其他一些細節上的技術如何，總的來說大的框架結構都是差不多的。
說白了，也就是mvc和三層結構。
而mvc和三層結構究竟是什麼關系，我曾在面試的過程中被人問過幾次，也曾仔細的想過、查過這個問題，但是直到此時，我也還是不能完全確定。
只不過隨著時間的積累，隨著技術的沉澱，隨著視野的拓寬，我大體上認同了兩種說法，不管別人怎麼看，我個人是覺得兩種說法都有道理，歡迎對這個問題有不同看法的朋友一起討論。
三層結構是什麼，是展現層、應用層、數據訪問層，這個基本上是沒有太大的異議的，兩種看法的來源基本上都是來自對於mvc的理解。
對於java web應用來說，不管是B/S還是C/S，大體上都可以分成服務端和客戶端兩部分，只不過B/S的客戶端就是公用的瀏覽器。
基於這種大的架構，有一種對於mvc的說法就是：
m是model，也就是和資料庫相關的那些，比如實體類和、mapper.xml等，對應著三層結構的數據訪問層；
v是view，也就是前台的頁面或者說是客戶端展示給用戶看的東西，也就是展現層；
而c就是controller以及service等具體的業務邏輯，對應著三層結構的應用層。123
而對於這種說法，為什麼我覺得有道理呢？是因為按照這種描述，就是和前台展示直接相關的東西都放在展現層。
*比如controller要直接和url打交道，而很多時候返回給客戶端的數據也會封裝成對象的形式，經常就是model；也就是說不管是controller還是model，都實打實和用戶看得到的部分相關，就劃為了展現層。
只不過在某些時候，就比如我們現在的項目中，為了進一步的實現松耦合，我們會創建一個command類，類似於實體model，然後用model操作資料庫，用command和前台打交道，道理是一樣的。
而在另一方面，我們現在項目前端使用的技術是angular js，這項技術現在也說實現了前台的mvc，有controller、service，還有數據層。
因此在這種情況下，我個人就覺得，mvc本就是一個概念，重要的是一種理解，它本身的作用只是為了實現松耦合，而不是為了mvc而mvc，未必一定要有一個唯一的答案！
歡迎有其他理解的朋友留言交流！
以下是我覺得比較好的其他理解：
來自網路的說法，是否是標准？
MVC（模型Model-視圖View-控制器Controller）是一種架構模式，可以用它來創建在域對象和UI表示層對象之間的區分。
同樣是架構級別的，相同的地方在於他們都有一個表現層，但是他們不同的地方在於其他的兩個層。
在三層架構中沒有定義Controller的概念。這是最不同的地方。而MVC也沒有把業務的邏輯訪問看成兩個層，這是採用三層架構或MVC搭建程序最主要的區別。當然了。在三層中也提到了Model，但是三層架構中Model的概念與MVC中Model的概念是不一樣的，「三層」中典型的Model層是以實體類構成的，而MVC里，則是由業務邏輯與訪問數據組成的。
這是來自網路知道的說法，是否專業？
MVC和三層架構有什麼區別就是MVC是最流行的三層架構中的一種框架，就是模型-視圖-控制器三者分離。
MVC模式（Model–view–controller）是軟體工程中的一種軟體架構模式，把軟體系統分為三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。
MVC模式最早由Trygve Reenskaug在1978年提出[1] ，是施樂帕羅奧多研究中心（Xerox
PARC）在20世紀80年代為程序語言Smalltalk發明的一種軟體架構。MVC模式的目的是實現一種動態的程式設計，使後續對程序的修改和擴展簡化，並且使程序某一部分的重復利用成為可能。除此之外，此模式通過對復雜度的簡化，使程序結構更加直觀。軟體系統通過對自身基本部分分離的同時也賦予了各個基本部分應有的功能。專業人員可以通過自身的專長分組：
控制器（Controller）- 負責轉發請求，對請求進行處理。 視圖（View） - 界面設計人員進行圖形界面設計。 模型（Model）
- 程序員編寫程序應有的功能（實現演算法等等）、資料庫專家進行數據管理和資料庫設計(可以實現具體的功能)。
來自來看日出的評論，我覺得有道理
無意中看到這個問題，我前段時間也想了很久，今天看到有點感觸，不知道您怎麼看，我一直其實有疑惑的(一個剛參加工作的新人)對於mvc的三層架構，設計理念是為了實現高內聚低耦合，您說得第一種三層結構，我覺得其實並沒有達到這個低耦合的效果，因為在應用層處理業務時，並沒有將真正的業務邏輯和資料庫邏輯分離開來，僅僅將視圖和邏輯分離開了，並沒有達到低耦合的效果，個人這並不是真正的MVC。
個人的理解，mvc應該分為5層。
1.視圖層(html/jsp/)等用戶能看得到的信息，數據信息的開始和結束。
2.控制層(servlet/action),控制層不處理任何業務(包括業務邏輯和資料庫邏輯)，只為控制流程，實現跳轉功能，只調用service層的結果實現跳轉功能，控制層的邏輯更偏向視圖層，為視圖層提供服務。
3.服務層(service)：專門處理業務邏輯，是控制層和DAO的中間過渡層，根據DAO層的返回結果的不同，處理不同的業務邏輯，並將結果向上返回給控制層。
4.DAO層：專門處理各種資料庫邏輯，包括對資料庫的CRUD，存儲過程/函數各種操作，提供訪問資料庫的介面，DAO層更偏向於model。
5.數據模型層：專門封裝數據原始模型(javabean/DTO)，本身不提供任何對資料庫的操作，只提供介面供DAO層調用數據。 從上到下依次為視圖層，控制層，服務層，DAO層，數據模型層。 個人理解，新人剛入門，有錯誤的地方希望指出共同學習。
我對來看日出的回復如下：
實際上，我個人現在的觀點是，我覺得我說的兩種都有道理，而你說的這一種也有道理，只看出發點是什麼，能不能說通。
你的這種說法，應該是實際開發時的代碼結構，後端通常有model、、service、controller，但是現在的前端，就比如我們用的angular js，實際上也分成了數據模型層、servie層、controller層、html展示層。
因此，我的理解是，網上常見的mvc解釋應該是針對之前整個系統架構比較簡單的情況，而現在前後端各種架構和技術都復雜起來了，可能便不能再這樣簡單的對應。
也就是說，我說的兩種實際上對於現在的情況可能都不對了。
隨著工作時間的增長，我對這個問題的看法一直在變，或許就是那句「看山是山，然後看山不是山，然後看山是山」，理解性的東西，本來就會隨著個人的閱歷增長而變化，今天覺得對的可能明天就覺得錯了。
所以，歸根結底，我覺得可以回到主題：我覺得對錯不重要，重要的是能不能說通，是不是自己的理解，對也好，錯也罷，能說的有理有據就夠了，因為理解會變。
❾ 請問JAVA三層架構，持久層，業務層，表現層，都該怎麼理解和MVC三層模型有什麼
這個嘛，有一定的聯系啦，也並不是完全是一樣的啦，你首先把mvc理解清楚吧，M是MODEL（模型）,V是view（視圖）， C是Controller（控制器），而java三層架構，持久層即是數據的持久化操作，就是數據層啦，即是資料庫啦，業務層主要是業務邏輯的處理，負責表示層與數據層（持久層）的數據的傳遞和邏輯處理，就當很接近控制器的功能啦，就可以理解為控制器啦，表示層即是對數據的展示與用戶的輸入，所以呢？就是視圖層啦 1. 用戶看到view2. view ——————————》 controller用戶操作（點擊按鈕等）3. controller——————》model調用model中方法3. model ——————》 controller返回數據到controller5. controller——————————》 view傳數據到view，更新view6.用戶看到更新後的view M——模型層，V——視圖層，C——控制層，持久層——通常用於封裝資料庫連接、數據查詢等操作，