什麼是mvc設計模式
㈠ 什麼是MVC設計模式，為什麼使用MVC
盡管最初的設計模式來源於城市和建築模式，但他的思想也同樣適用於面向對象設計模式，只是在面向對象的解決方案里，我們用對象和介面代替了牆壁和門窗。
㈡ 什麼是設計模式,MVC中都用到了哪些設計模式。
「每一個模式描述了一個在我們周圍不斷重復發生的問題，以及該問題的解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重復勞動」
盡管最初的設計模式來源於城市和建築模式，但他的思想也同樣適用於面向對象設計模式，只是在面向對象的解決方案里，我們用對象和介面代替了牆壁和門窗。兩類模式的核心都在於提供了相關問題的解決方案。
一般而言，一個模式有四個基本要素：
1. 模式名稱（pattern name） 一個助記名，它用一兩個詞來描述模式的問題、解決方案
和效果。
2. 問題(problem) 描述了應該在何時使用模式。
3. 解決方案(solution) 描述了設計的組成成分，它們之間的相互關系及各自的職責和協
作方式。
4. 效果(consequences) 描述了模式應用的效果及使用模式應權衡的問題。
類的模型/視圖/控制器（Model/View/Controller）三元組(MVC)被用來構建用戶界面。透過MVC 來看設計模式將幫助我們理解「模式」這一術語的含義。
MVC包括三類對象。模型Model是應用對象，視圖View是它在屏幕上的表示，控制器Controller定義用戶界面對用戶輸入的響應方式。不使用MVC，用戶界面設計往往將這些對象混在一起，而MVC則將它們分離以提高靈活性和復用性。
MVC通過建立一個「訂購/通知」協議來分離視圖和模型。視圖必須保證它的顯示正確地反映了模型的狀態。一旦模型的數據發生變化，模型將通知有關的視圖，每個視圖相應地得到刷新自己的機會。這種方法可以讓你為一個模型提供不同的多個視圖表現形式，也能夠為一個模型創建新的視圖而無須重寫模型。
㈢ 什麼是mvc模式
MVC(Model/View/Controller)模式是國外用得比較多的一種設計模式，好象最早是在Smaltalk中出現。MVC包括三類對象。Model是應用對象，View是它在屏幕上的表示，Controller定義用戶界面對用戶輸入的響應方式。
模型-視圖-控制器（MVC）是80年代Smalltalk-80出現的一種軟體設計模式，現在已經被廣泛的使用。
1、模型（Model）
模型是應用程序的主體部分。模型表示業務數據，或者業務邏輯.
2、視圖（View）
視圖是應用程序中用戶界面相關的部分，是用戶看到並與之交互的界面。
3、控制器（controller)
控制器工作就是根據用戶的輸入，控制用戶界面數據顯示和更新model對象狀態。
MVC 式的出現不僅實現了功能模塊和顯示模塊的分離，同時它還提高了應用系統的可維護性、可擴展性、可移植性和組件的可復用性
早期的程序中，如果不注意對數功能和顯示的解耦合，常常會導致程序的復雜及難以維護。很多VB,Delphi等RAD程序都有這種問題。甚至現在的C#,Java有時候也會出現把業務邏輯寫在顯示模塊中的現象
管MVC設計模式很早就提出，但在Web項目的開發中引入MVC卻是步履維艱。主要原因：一是在早期的Web項目的開發中，程序語言和HTML的分離一直難以實現。CGI程序以字元串輸出的形式動態地生成HTML內容。後來隨著腳本語言的出現，前面的方式又被倒了過來，改成將腳本語言書寫的程序嵌入在HTML內容中。這兩種方式有一個相同的不足之處即它們總是無法將程序語言和HTML分離。二是腳本語言的功能相對較弱，缺乏支持MVC設計模式的一些必要的技術基礎。直到基於J2EE的JSP Model 2問世時才得以改觀。它用JSP技術實現視圖的功能，用Servlet技術實現控制器的功能，用JavaBean技術實現模型的功能
JSP Model 1 與 JSP Model 2
SUN在JSP出現早期制定了兩種規范，稱為Model1和Model2。雖然Model2在一定程度上實現了MVC，但是它的應用用並不盡如人意
JSP Model 1
JSP Model 2
model2 容易使系統出現多個Controller，並且對頁面導航的處理比較復雜
有些人覺得model2仍不夠好，於是Craig R. McClanahan 2000年5月提交了一個WEB framework給Java Community.這就是後來的Struts.
2001年7月，Struts1.0，正式發布。該項目也成為了Apache Jakarta的子項目之一
Struts 質上就是在Model2的基礎上實現的一個MVC架構。它只有一個中心控制器，他採用XML定製轉向的URL。採用Action來處理邏輯
㈣ 什麼是MVC設計模式，如何使用MVC
MVC模式解釋，以及如何使用mvc的解釋如下：
模型-視圖-控制器（MVC模式）是一種非常經典的軟體架構模式，在UI框架和UI設計思路中扮演著非常重要的角色。從設計模式的角度來看，MVC模式是一種復合模式，它將多個設計模式在一種解決方案中結合起來，用來解決許多設計問題。MVC模式把用戶界面交互分拆到不同的三種角色中，使應用程序被分成三個核心部件：Model（模型）、View（視圖）、Control（控制器）。它們各自處理自己的任務：
（1）模型：模型持有所有的數據、狀態和程序邏輯。模型獨立於視圖和控制器。
（2）視圖：用來呈現模型。視圖通常直接從模型中取得它需要顯示的狀態與數據。對於相同的信息可以有多個不同的顯示形式或視圖。
（3）控制器：位於視圖和模型中間，負責接受用戶的輸入，將輸入進行解析並反饋給模型，通常一個視圖具有一個控制器。
㈤ MVC設計模式是什麼怎麼理解
什麼是MVP
View ：是指顯示數據並且和用戶交互的層。在安卓中，它們可以是一個Activity，一個Fragment，一個android.view.View或者是一個Dialog。
Model ：是數據源層。比如資料庫介面或者遠程伺服器的api。
Presenter：是從Model中獲取數據並提供給View的層，Presenter還負責處理後台任務。
MVP是一個將後台任務和activities/views/fragment分離的方法，讓它們獨立於絕大多數跟生命周期相關的事件。這樣應用就會變得更簡單，整個應用的穩定性提高10倍以上，代碼也變得更短，可維護性增強，程序員也不會過勞死了~~。
為什麼要在安卓上使用MVP原因一: 盡量簡單
如果你還沒有閱讀過這篇文章，閱讀它: Kiss原則(https://people.apache.org/%7Efhanik/kiss.html)。- kiss是Keep It Stupid Simple或者Keep It Simple, Stupid的縮寫。
.絕大多數的安卓程序都只使用了View-Model架構。
.程序員被絞盡了復雜的界面開發中，而不是解決事務邏輯。
在應用中使用Model-View的壞處是「每個東西之間都是相互關聯的」如下圖:
如果上面的圖解看起來還不夠復雜，那麼想想這些情況：每個view可能在任意的時間出現或者消失，view數據需要保存與恢復，在臨時的view上掛載一個後台任務。
而與「每個東西之間都是相互關聯的」的相反選擇是使用一個萬能對象（god object）。註：god object是指一個對象/常式在系統中做了太多的事情，或者說是有太多不怎麼相關的事情放在一個對象/常式裡面來完成。
god object過於復雜，他的不同部分無法重用、測試，無法輕易的debug和重構。
使用MVP
復雜的任務被分割成簡單的任務。
.更小的對象，更少的bug。
.更好測試
MVP的view層變得如此簡單，在請求數據的時候甚至不需要使用回調。view的邏輯變得非常直接。
原因二: 後台任務
當你需要寫一個Activity，Fragment或者一個自定義View的時候，你可以將所有和後台任務相關的方法放在一個外部的或者靜態的類中。這樣你的後台任務就不會再與Activity相關聯，不會在泄漏內存同時也不會依賴於Activity的重建。我們稱這樣的一個類為「Presenter」。註：要理解此話的含義最好先看懂第一個MVP示例的代碼。
雖然有一些方法可以解決後台任務的問題，但是沒有一種和MVP一樣可靠。
為什麼這是可行的
下面的圖解顯示了在configuration改變或者發生out-of-memory事件的情況下應用的不同部分所發生的事情。每一個開發者都應該知道這些數據，但是這些數據並不好發現。
| Case 1 | Case 2 | Case 3
|A configuration| An activity | A process
| change | restart | restart
---------------------------------------- | ------------- | ------------ | ------------
Dialog | reset | reset | reset
Activity, View, Fragment | save/restore | save/restore | save/restore
Fragment with setRetainInstance(true) | no change | save/restore | save/restore
Static variables and threads | no change | no change | reset
情景1：configuration的改變通常發生在旋轉屏幕，修改語言設置，鏈接外部的模擬器等情況下。要知道更多的configuration change事件請閱讀：configChanges（developer.android.com/reference/android/R.attr.html#configChanges）。
情景2：Activity的重啟發生在當用戶在開發者選項中選中了「Don't keep activities」（「中文下為 不保留活動」）的復選框，然後另一個Activity在最頂上的時候。
情景3：進程的重啟發生在應用運行在後台，但是這個時候內存不夠的情況下。
結論
現在你可以發現，一個擁有setRetainInstance(true)的Fragment並沒有帶來幫助 - 我們還是要保存和/恢復這種fragment的狀態。因此我們可以去掉可保持Fragment的情景，把問題簡單化。Occam's razor（https://en.wikipedia.org/wiki/Occam%27s_razor）
㈥ 什麼是MVC設計模式（不要復制百度百科的，看不懂）
業務場景
你需要找水電公司修一下水管
Controller ：即你要先打電話給他們的業務。
負責接收你的請求，然後轉發給去實現的人
Model：然後業務找到技術工人
負責實現的人，他有自己的一套技術可以修好水管
View：業務到你家修好水管
呈現給你的結果 ，到你們家，修好了你的水管
㈦ mvc設計模式分別是哪些彼此之間作用是什麼
MVC就是
M:Model 模型
V:View 視圖
C:Controller 控制器
模型就是封裝業務邏輯和數據的一個一個的模塊,控制器就是調用這些模塊的(java中通常是用Servlet來實現,框架的話很多是用Struts2來實現這一層),視圖就主要是你看到的,比如JSP等.
當用戶發出請求的時候,控制器根據請求來選擇要處理的業務邏輯和要選擇的數據,再返回去把結果輸出到視圖層,這里可能是進行重定向或轉發等.MVC我感覺主要就是把一個軟體或網站清晰地分成幾部分,每一部分都實現自己的功能,當某一部分需要修改時就可以只修改這一部分,不會去修改整體,當後期維護的時候MVC的作用也是很大的,耦合度太高就會導致牽一發而動全身,開銷也就會非常大了,現在的很多軟體都是要很多人完成的,不過不把軟體清晰的分層,不把軟體模塊化,大家就很難做好自己的那一塊,好多人都可能做了同一部分,而且沒辦法整合到一起,所以MVC我感覺是一種軟體架構思想,我也是新手,可能理解的不是很深,我就把我體會到的說了一下哈,希望大牛們批評更正哈!!!
㈧ MVC設計模式是什麼 怎麼理解
MVC就是
M:Model 模型
V:View 視圖
C:Controller 控制器
模型就是封裝業務邏輯和數據的一個一個的模版塊權,控制器就是調用這些模塊的(java中通常是用Servlet來實現,框架的話很多是用Struts2來實現這一層),視圖就主要是你看到的,比如JSP等.
當用戶發出請求的時候,控制器根據請求來選擇要處理的業務邏輯和要選擇的數據,再返回去把結果輸出到視圖層,這里可能是進行重定向或轉發等.MVC我感覺主要就是把一個軟體或網站清晰地分成幾部分,每一部分都實現自己的功能,當某一部分需要修改時就可以只修改這一部分,不會去修改整體,當後期維護的時候MVC的作用也是很大的,耦合度太高就會導致牽一發而動全身,開銷也就會非常大了,現在的很多軟體都是要很多人完成的,不過不把軟體清晰的分層,不把軟體模塊化,大家就很難做好自己的那一塊,好多人都可能做了同一部分,而且沒辦法整合到一起,所以MVC我感覺是一種軟體架構思想,我也是新手,可能理解的不是很深,我就把我體會到的說了一下哈,希望大牛們批評更正哈!!!
㈨ 如何理解MVC設計模式
MVC(Model/View/Controller)模式是國外用得比較多的一種設計模式，好象最早是在Smaltalk中出現。MVC包括三類對象。Model是應用對象，View是它在屏幕上的表示，Controller定義用戶界面對用戶輸入的響應方式。
模型-視圖-控制器（MVC）是80年代Smalltalk-80出現的一種軟體設計模式，現在已經被廣泛的使用。
1、模型（Model）
模型是應用程序的主體部分。模型表示業務數據，或者業務邏輯.
2、視圖（View）
視圖是應用程序中用戶界面相關的部分，是用戶看到並與之交互的界面。
3、控制器（controller)
控制器工作就是根據用戶的輸入，控制用戶界面數據顯示和更新model對象狀態。
MVC 式的出現不僅實現了功能模塊和顯示模塊的分離，同時它還提高了應用系統的可維護性、可擴展性、可移植性和組件的可復用性
早期的程序中，如果不注意對數功能和顯示的解耦合，常常會導致程序的復雜及難以維護。很多VB,Delphi等RAD程序都有這種問題。甚至現在的C#,Java有時候也會出現把業務邏輯寫在顯示模塊中的現象
管MVC設計模式很早就提出，但在Web項目的開發中引入MVC卻是步履維艱。主要原因：一是在早期的Web項目的開發中，程序語言和HTML的分離一直難以實現。CGI程序以字元串輸出的形式動態地生成HTML內容。後來隨著腳本語言的出現，前面的方式又被倒了過來，改成將腳本語言書寫的程序嵌入在HTML內容中。這兩種方式有一個相同的不足之處即它們總是無法將程序語言和HTML分離。二是腳本語言的功能相對較弱，缺乏支持MVC設計模式的一些必要的技術基礎。直到基於J2EE的JSP Model 2問世時才得以改觀。它用JSP技術實現視圖的功能，用Servlet技術實現控制器的功能，用JavaBean技術實現模型的功能
JSP Model 1 與 JSP Model 2
SUN在JSP出現早期制定了兩種規范，稱為Model1和Model2。雖然Model2在一定程度上實現了MVC，但是它的應用用並不盡如人意
JSP Model 1
JSP Model 2
model2 容易使系統出現多個Controller，並且對頁面導航的處理比較復雜
有些人覺得model2仍不夠好，於是Craig R. McClanahan 2000年5月提交了一個WEB framework給Java Community.這就是後來的Struts.
2001年7月，Struts1.0，正式發布。該項目也成為了Apache Jakarta的子項目之一
Struts 質上就是在Model2的基礎上實現的一個MVC架構。它只有一個中心控制器，他採用XML定製轉向的URL。採用Action來處理邏輯
へ傷苡趫載ご 回答時間 2008-02-20 20:49
其他答案MVC就是模型,視圖,控制器.
模型不用說了吧,視圖只負責顯示,不要帶任何邏輯.控制器就是負責控制.
遵循這個思想就可以了。
現在有很多MVC的框架.比如JAVA EE 的STRUTS之類的.
㈩ MVC設計模式了解什麼是mvc
Model（模型），是程序的主體部分，主要包含業務數據和業務邏輯。在模型層，還會涉及到用戶發內布的服務，在服務中容會根據不同的業務需求，更新業務模型中的數據。
View(視圖），是程序呈現給用戶的部分，是用戶和程序交互的介面，用戶會根據具體的業務需求，在View視圖層輸入自己特定的業務數據，並通過界面的事件交互，將對應的輸入參數提交給後台控制器進行處理。
Controller（控制器），Controller是用來處理用戶輸入數據，已經更新業務模型的部分。控制器中接收了用戶與界面交互時傳遞過來的數據，並根據數據業務邏輯來執行服務的調用和更新業務模型的數據和狀態。