（1）三層架構和MVC模式。
不知道大家有沒有和我的類似經歷。記得大學一次看見班長在學習JAVA中的MVC。就很好奇的問：班長，MVC到底是啥子嘛？）班長回答了半天總結出一句話：MVC就是“控制器，視圖，模型”，和三層架構差不多。難道MVC就是分別對應了三層架構中的“DAL,BLL和UI”？下面分別分析下三層架構和MVC模式。
三層架構，在長期的軟件開發過程中，人們經歷了"UI"--->“UI+BLL”---> “UI+BLL+DAL”三種時代--->.....。
UI層時代：人們通常把所有的表現、業務邏輯和數據庫訪問的代碼都放在一起。這樣做的結果是維護起來是相當困難的，因為一旦遇見需求變更，維護起來將是一件相當麻煩的事情。也許你只想更改數據訪問的一段代碼，但是可能造成的結果卻是你不得不修改大片業務邏輯和變現代碼。因此，人們提出了“單一職責”和“職責分離”的原則，決定將表現和業務邏輯分開，這樣就形成了“UI層”和“BLL”，他們之間由“服務接口”相連（依賴倒置原則），彼此活動互不影響。於是，聰明的人們就進入下一時代。
UI+BLL層時代：表現和業務邏輯的分離讓我們更好的完成開發，但是為了降低數據訪問和業務邏輯間的冗余，人們開始進入三層架構甚至多層架構的時代。
有了三層架構，人們可以很輕松的面對需求變更（也有可能出現各層級聯修改的情況，這就要考軟件設計師的功夫了，做到“開放關閉”），但是回到最開始的WEB層時代，現在的“表現層”就相當於當時的"WEB層"，只是外面將業務邏輯和數據訪問等代碼分離。但是，表示層依然會出現后台代碼和展示混在一起的情況，但是至少不會或很少出現維護繁瑣的情況。為了更好的實現“職責分離”，MVC模式誕生了。 Model層實現系統中的業務邏輯，View層用於與用戶的交互， Controller層用於接收VIew提交的用戶數據並轉發給相應的Model，同時接收Model的數據處理結果轉發給View。這樣表現層的代碼徹底做到“職責分離”了。
下面我們做三種假設：第一、項目中，僅僅運用MVC模式。第二、項目中，僅僅運用三層架構。第三、項目中，同時運用MVC模式和三層架構。
假設一，在項目中，所有的業務邏輯和數據庫訪問均由Model承擔。這樣的Model是不是略顯臃腫呢?如果我僅僅改動數據訪問會不會影響大片的業務邏輯代碼呢？個人認為，不可取。
假設二，在項目中，僅運用三層架構，如上所說，至少邏輯上的變化不大，有問題也是表示層內部的事情。個人認為可取。
假設三，在項目中，運用三層架構可以減少邏輯和表現等方面的冗余，運用MVC又可以減少變現層內部的冗余。個人認為可取。
特別注意：以上三種假設和三種時代的划分，均是在項目足夠大和足夠復雜的前提下進行的。個人認為，技術架構的選擇應該由項目環境決定，而不是越好的技術結構就能開發出越好的項目。比如說用C#開發一個小心的計算器，個人認為沒有必要用什么架構和模式了（排除項目需求擴展等情況），如果用什么三層架構、MVC，開發成本就太大了，而且架構在一定程度上也會影響項目的性能 。
總結：1、三層架構和MVC模式並沒有必然的關聯，只不過是不同重心和程度上的解耦。三層注重解耦表現、業務邏輯和數據訪問。MVC模式注重表現和邏輯（包括業務邏輯和數據訪問等等）上的解耦，在一定程度上，三層架構的解耦更深，MVC的解耦更細。
2、如果三層架構和MVC模式同時運用，MVC則側重於解耦表現和業務邏輯接口， 和MVP,MVVM等模式一樣構成表現層上的解耦。和BLL中的領域模型模式、DAL中的ORM模式等等一樣
（2）ASP.NET MVC == MVC？？？
仔細看出其實MVC其實由兩條路組成：第一、Model和View直接通信。第二、Model和View通過Controller進行通信。而ASP.NET MVC就是第二條路的一個實現（策略模式）。第一條路就是外面常用的ASP.NET Form的實現，通過事件驅動模型（觀察者模式）和回發機制（postback）實現Model和View之間的通信，到底微軟為啥子不直接叫MVC，這個還真不曉得。 至於兩條路同時走，這個我真不知道。
總結： ASP.NET MVC不過是MVC的一種實現，ASP.NET MVC 不等於MVC。
（3）、MVC是屬於JAVA的嘛？
一開始MVC在Java中的運用非常廣泛，所以像我這樣苦逼的程序員在上學的時候都以為MVC是JAVA的固有特性，其實不然。MVC是一種思想，是無數個苦逼程序員經驗和分析的積累。而Java中的MVC僅僅是僅僅是MVC的一種和Castle mvc，ASP.NETMVC一樣。
總結 :MVC是對前人無數經驗的思考和總結而得出的一種架構思想。
(4)、ASP.NET MVC是否將取代ASP.NET ？
ASP.NET MVC是否將取代ASP.NET?在項目開發的過程中，外面是否應該放棄ASP.NET，而用ASP.NET MVC？這是我剛看到MVC遇見過的問題。ASP.NET MVC 沒有在繼續ASP.NET的道路---事件驅動+回發，而是回到最原始的時期，給我們提供了一條新的道路。正如上面第二點所說。兩者各有千秋。
ASP.NET MVC的優勢:
ASP.NET MVC由前端控制器模式的思想實現。這使的他具有非常完美的地址映射。
ASP.NET MVC通過控制器、視圖、模型的結構，可以更好的組織邏輯，解決復雜問題。
ASP.NET MVC更容易進行單元測試，有利於“測試驅動開發”--OOT；
ASP.NET MVC的掠勢：
在開發過程中無法使用設計--代碼的切換，不能做到所見即所得。無法使用控件等進行快速開發。無法使用視圖狀態（ViewState）等。。。。等等等等。
總結,從上面的陳訴可以看到，ASP.NET MVC面對開發，出現了很多不能，這些不能可以為我們的開發提供很多的便利，比如開發成本、周期、效益等等方面。可以看出，ASP.NET MVC並不能動搖ASP.NET的地位。個人認為，如果你是一個期望用短期的時間收獲比較高的效益，而且你的項目復雜度較低，ASP.NET是最佳的選擇。如果面臨比較復雜的業務邏輯，ASP.NET MVC可以更好的幫助我們組織並實現它。
貌似，當初的疑惑就只有這些，后面開始慢慢的總結下ASP.NET MVC的東東。