標籤:

MVC 架構與 Observer 模式有什麼異同點?

比如說我寫一個有一個int和兩個button(+)(-)的界面,每當按鈕被點擊,調用邏輯層的add或sub方法,然後把這個對象持久化,然後調用int的display方法,該方法是直接從數據層讀取表格並展示,那麼這個屬於MVC么?屬於Observer么?//被批評耦合度高,那我就稍微改一下O_o

class Frame{
int i;
button add;
button sub;
Logic logic;
Data data;

void add(){
logic.add();
display();
}

void sub(){
logic.sub();
display();
}

void display(){
i=data.get(i);
}
}

interface logic{
void add();
void sub();
}

interface data{
void setI(int i);
int getI();
}

這樣應該不存在循環依賴了,UI依賴Logic和Data,Logic依賴Data


謝邀。

MVC是軟體架構,Observer是設計模式,是不同層面的東西,不能直接比較異同。

MVC本質上是解耦,讓UI和邏輯,數據分離。一旦應用,基本上整個項目都要遵從這種模式。

Observer是一種傳遞消息的機制,特點是被觀察者不需要知道觀察者是誰,降低了耦合。這是一種模式,三兩個class就可以實現,對網站構架沒有影響。

如果硬要說聯繫,Observer模式經常被應用在MVC架構中,作為一種消息處理的機制。


幾個函數互相調用居然能扯出這麼多東西……up主有點厲害。


MVC是一個複合模式,其中包括Observor,去看GoF的《設計模式》

你的例子不是觀察者,還是先去看書吧。


我想了很久給這種模式取個名字,應該叫多層電路板模式

也就是說看起來有很多層,但是實際上都粘在一起,而且每一個焊點都是一個通孔,從第一層通到最後一層。

對於初學者而言,與其追逐這些無法理解的模式,不如老老實實寫個能用的東西出來,有些東西自然就明白了。


MVC模式是複合模式,包含觀察者模式。加入控制器C是為了把模型和視圖分離

M和C之間是策略模式,表示對同樣的數據可以有不同的處理演算法;

M和V之間是觀察者模式,V表示觀察者;

M本身的管理可能用到組合模式,用於管理具有層次性的對象。

參考《Head. First 設計模式》

圖片來自百度百科

PS:書上講的只是比較經典的例子,在實際環境中有很多的變體和改進,只要體會其中思想,無需嚴格跟書上的相同。另外,J2EE框架的學習一定要理解MVC模式。


顯然不是么,耦合得那麼厲害。


MVC是關於如何組織代碼和數據的方法,讓他們分工合作,使程序的結構清晰易懂,便於擴展和維護,它描述的是程序的結構,是對程序的抽象。

MVC模式的程序被分為模型層,視圖層,控制層。

設計模式是如何設計【類】,如何使用【對象】,以求代碼運行可靠,穩定,高效。

外行人的胡說,如有雷同,純屬巧合。


題主這種碰到想不明白的事情按自己的理解做出解讀的方式還是值得鼓勵的,mvc或observer 對於剛接觸對象設計來說是挺費腦筋,個人認為這些東西有點類似於解題方法或技巧,對於技巧和方法,更重要的其實是題目,對題目去給出自己的設計之後,再來思考技巧和方法,或許理解更透徹,能給出更有自己想法的解讀方式。


目測這個問題能把溫趙輪都吸引過來,現在只差輪子哥了。溫大已經說的很清楚了,這兩個概念沒什麼關係。

題主的代碼,既沒有MVC,也沒有Observer。


mvc不是一個代碼片段,也不是一種實現技巧,所以它不是設計模式。

mvc是一種開發的解耦模型,綜合使用了各種設計模式來達到解耦的目的。貫徹mvc的想法,能讓代碼的復用能力上一個台階。

mvc的模型會用到觀察者的設計模式。


看著樓主被噴,心情甚是不佳


題主大學生吧。在知乎上問問題要有自知之明哦,不然會被噴很慘。


我是來吐槽的,只說一句話...

Observer是設計模式

MVC是軟體架構

淺一點理解軟體架構是多種設計模式交織在一起的平台...

題主進行對比的兩個玩意都不在一個層次上...

前面大牛太多了,摺疊我吧...


model view controller

這代碼,瞎雞巴寫啊。

logic data都是m層的。

m 與 v完全不能有關聯。只能同時出現在controller裡面。

總之不懂的話先找點資料看看成嗎。基本概念都不清楚。


樓主你的代碼能formatter下嘛?不縮進看著難受啊。。


看到代碼再看看問題,確實有掛羊頭賣狗肉的意思,如果非要從代碼找一點設計模式的影子,可能和策略模式沾點邊!再說一下observer模式,這個模式有2個主要模型,一種是我們店裡來新菜了,然後通知會員們快來挑菜吧,什麼菜我不告訴你,你自己來看;另一種是我拿到了一個新菜的聯繫方式,然後我大公無私的告訴每一位好友,去不去約你們自己看著辦,和我無關,因為我壓根就沒看這個聯繫方式!


你寫的代碼跟mvc和設計模式沒有關係。


在這裡評論、提問,要有被噴的思想覺悟。。。

我說說我的理解, 僅供參考:

MVC是一個代碼邏輯解耦的思想。

頁面/界面&<—&>控制器&<—&>數據邏輯。

view&<—&>controller&<—&>model。

你試試一個查詢寫在jsp頁面裡面,你應該就知道為何要分層了。

而觀察者模式(發布/訂閱模式)是:主題的狀態變化後,主動通知觀察者。

推送消息、線程模型、事件驅動等情況下會跟觀察者模式有關係。

回到問題,MVC的架構與觀察者模式有啥異同點?

很勉強的說,某些情況下MVC架構的請求分發(controller)可以由觀察者模式來表達。比如說model層的data發生變化了, 主動告知view。

能力有限,其他我想不到了。


MVC是業務切割吧,簡單地說是一個項目好多人做,但是都沒完成其餘部分就一起開工的情況,通常都是使用一種比較重型的框架。設計模式的話,基本是和框架無關的。


貌似 MVC 是在 controller 中既綁定對應的模型又綁定對應的視圖,並且綁定其模型所觸發的事件,以在回調函數中渲染 UI...


mvc一對一對一,另一個一對n


MVC M對應Model V對應View C對應Control

好吧,說下自己的理解。 簡單粗暴點來說,

1. M對應後台,一般可以先針對數據表來建bean,然後對錶插刪改查的操作可以定義為IXxModel介面,再來個ImplIXxModel去實現介面,至此M層完畢,前提是要會針對實際情況建好表。

2. V對應前台界面,可以想成是IXxView介面和實現介面的ImplIXxView這2部分組成,V層通過調用C層實現對M層的操縱,為了低耦合,V層只能藉助C層,不要在V層裡面直接調用M層。為什麼呢?後面再說吧。

3. C層負責邏輯處理,C層直接調用M層,對於涉及View的參數或操作可以抽放在view介面中,藉助事件驅動方式給C層用,好吧,其實簡單點說,C層就是利用M層介面和V層介面這2個人,實現邏輯處理,抽成方法專一提供給V層用。

就是MVC

為什麼呢,其實是為了有利於分工,想想看,做M層的只要知道表就可以了,反正一般做M層的為了純潔度是只會給你setter,getter而已的。這樣做M層的人的工作就這樣清楚了。

做界面的呢,嗯。。。知道了M層那邊只會給最基本的setter,getter後,先實現基本的界面View層的繪製,然後針對邏輯處理,去設計View介面,或者直接在C層封裝對M層操作的方法給V層用。

一般對我來說,無法做到一次完美分層,但是會把大部分邏輯處理都放在C層,M層只調用C層的方法就好,之後再進行一次一次的重構,這樣代碼耦合度就會越來越低。

好吧,其實覺得自己一次性代碼寫的不夠好的,要有不斷去重構的心裡準備啊。。。。可能重構久了水平會提高點,也許以後就不用寫完重構太多(? ??_??)?


推薦閱讀:

c++ 單例模式的一點疑問,求解答?
在替考的代理模式中到底誰是Proxy?
怎樣才能在寫代碼時沒有一種「如履薄冰」的感覺?
用 C++ 編程時,如果不使用設計模式,多層封裝,採用複雜的數據結構,代碼更直觀,易理解,引入(設計模式)後雖然做到了高度的解耦。但是代碼邏輯複雜了,怎麼平衡好?
有哪些在實際 Android 項目中用到的設計模式?

TAG:MVC | 設計模式 |