筋骨皮模式（Model模型-View檢視-Controller控制器）是軟體工程中的一種軟體架構模式。它把軟體系統分為三個基本部分：骨架（Model模型），表皮（View檢視）和筋（Controller控制器）。
筋骨皮模式最早由Trygve Reenskaug在1974年[1]提出，是全錄帕羅奧多研究中心（Xerox PARC）在20世紀80年代為程式語言Smalltalk發明的一種軟體設計模式。筋骨皮模式的目的是實作一種動態的程式設計，使後續對程式的修改和擴充功能簡化，並且使程式某一部分的重複利用成為可能。除此之外此模式透過對複雜度的簡化使程式結構更加直覺。軟體系統透過對自身基本部份分離的同時也賦予了各個基本部分應有的功能。專業人員可以透過自身的專長封包：
- 筋（控制器Controller）- 負責轉發請求，對請求進行處理。
- 表皮（檢視View） - 介面設計人員進行圖形介面設計。
- 骨架（模型Model） - 程式設計師編寫程式應有的功能（實作演算法等等）、資料庫專家進行資料管理和資料庫設計(可以實作具體的功能)。
層次
骨架（Model模型） 「資料模型」（Model）用於封裝與應用程式的業務邏輯相關的資料以及對資料的處理方法。「模型」有對資料直接存取的權力，例如對資料庫的存取。「模型」不依賴「檢視」和「控制器」，也就是說，模型不關心它會被如何顯示或是如何被操作。但是模型中資料的變化一般會透過一種重新整理機制被公布。為了實作這種機制，那些用於監視此模型的檢視必須事先在此模型上註冊，從而，檢視可以了解在資料模型上發生的改變。（比較：觀察者模式（軟體設計模式））
外皮（View檢視） 檢視層能夠實作資料有目的的顯示（理論上，這不是必需的）。在檢視中一般沒有程式上的邏輯。為了實作檢視上的重新整理功能，檢視需要存取它監視的資料模型（Model），因此應該事先在被它監視的資料那裡註冊。
筋（Controller控制器） 控制器起到不同層面間的組織作用，用於控制應用程式的流程。它處理事件並作出響應。「事件」包括使用者的行為和資料模型上的改變。
優點
在最初的JSP網頁中，像資料庫查詢語句這樣的資料層代碼和像HTML這樣的表示層代碼混在一起。經驗比較豐富的開發者會將資料從表示層分離開來，但這通常不是很容易做到的，它需要精心地計劃和不斷的嘗試。筋骨皮模式從根本上強制性地將它們分開。儘管構造筋骨皮模式應用程式需要一些額外的工作，但是它帶給我們的好處是毋庸置疑的。
首先，多個檢視能共享一個模型。如今，同一個Web應用程式會提供多種使用者介面，例如使用者希望既能夠透過瀏覽器來收發電子郵件，還希望透過手機來存取電子郵箱，這就要求Web網站同時能提供Internet介面和WAP介面。在筋骨皮設計模式中，模型響應使用者請求並返迴響應資料，檢視負責格式化資料並把它們呈現給使用者，業務邏輯和表示層分離，同一個模型可以被不同的檢視重用，所以大大提高了代碼的可重用性。
其次，骨架是自包含的，與筋和皮保持相對獨立，所以可以方便的改變應用程式的資料層和業務規則。如果把資料庫從MySQL移植到Oracle，或者把RDBMS資料來源改變成LDAP資料來源，只需改變骨架即可。一旦正確地實作了骨架，不管資料來自資料庫還是LDAP伺服器，檢視都會正確地顯示它們。由於筋骨皮模式的三個模組相互獨立，改變其中一個不會影響其他兩個，所以依據這種設計思想能構造良好的少互擾性的構件。
此外，控制器提高了應用程式的靈活性和可配置性。控制器可以用來連線不同的模型和檢視去完成使用者的需求，也可以構造應用程式提供強有力的手段。給定一些可重用的模型和檢視，控制器可以根據使用者的需求選擇適當的模型機型處理，然後選擇適當的的檢視將處理結果顯示給使用者。
缺點及適用範圍
筋骨皮模式的缺點是由於它沒有明確的定義，所以完全理解筋骨皮模式並不是很容易。使用筋骨皮模式需要精心的計劃，由於它的內部原理比較複雜，所以需要花費一些時間去思考。開發一個筋骨皮模式架構的工程，將不得不花費相當可觀的時間去考慮如何將筋骨皮模式運用到應用程式中，同時由於模型和檢視要嚴格的分離，這樣也給偵錯應用程式帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。另外由於筋骨皮模式將一個應用程式分成了三個部件，所以這意味著同一個工程將包含比以前更多的檔案。
因此筋骨皮模式並不適合小型甚至中等規模的應用程式，這樣會帶來額外的工作量，增加應用的複雜性。但對於開發存在大量使用者介面，並且邏輯複雜的大型應用程式，筋骨皮模式將會使軟體在健壯性、代碼重用和結構方面上一個新的台階。儘管在最初構建筋骨皮模式框架時會花費一定的工作量，但從長遠的角度來看，它會大大提高後期軟體開發的效率。
實作
MFC
微軟所推出的MFC Document/View架構是早期對於筋骨皮模式的實作，MFC將程式分成CView以及CDocument兩大類別，其中的Document對應筋骨皮模式中的Model，View相當於筋骨皮模式中的View＋Controller，再加上CWinApp類別，合成三大項。但是基本上MFC是一個失敗的筋骨皮模式作品。
由於MFC之下的Document/View定義過於模糊，未將Controller（MessageMap）部份取出，因此Controller可以置入View或Document，但不管置入哪一方面，都會與View或Document綁死，沒有彈性。
Java
Java 平台企業版 (J2EE)
和其他的各種框架不一樣，J2EE為模型物件（Model Objects）定義了一個規範。
- 檢視(View)
- 在J2EE應用程式中，檢視（View）可能由Java Server Page(JSP)承擔。生成檢視的代碼則可能是一個servlet的一部分，特別是在用戶端伺服端互動的時候。
- 控制器（Controller）
- J2EE應用中，控制器可能是一個servlet，現在一般用Struts實作。
- 模型（Model）
- 模型則是由一個實體Bean來實作。
Java Swing
Swing是一個標準的MVC結構. ComponentUI代表View, 負責描畫元件. 元件尤其Model層, 比如JTextField的Document, JTable的TableModel, JTree的TreeModel等等. 而Control可能不是很明顯, 我們或許可以簡單的將其Event機制看作一個Swing團隊開發給開發者的Controller.
作為Java開發者, 如果想理解MVC的結構, 學習Swing的確是個不錯的選擇.
.NET
ASP.NET
在ASP.NET中，針對檢視（View）和控制器（Controller）的模式沒有被很好地定義。而模型（Model）則留給開發者去設計。
- 外皮（View檢視）
- ASPX和ASCX檔案被用來處理檢視的職責。在這個設計中檢視實際上是從控制器繼承而來。這個和Smalltalk的實施有所不同，在Smalltalk中不同的類都有指標互相指向對方.
- 筋（Controller控制器）
- 控制器的職責被分割成兩部分。事件（Event）的產生和傳輸是框架的一部分，更明確的說是Page和Control兩個類。而事件的處理則在分離的代碼中實作。
- 骨架（Model模型）
- ASP.NET 不嚴格需要一個模型。開發者可以自行選擇建立一個模型類，但是很多人選擇放棄這一步，直接把事件處理放在控制器里處理任何計算、資料保存等等。但用模型來包含商業邏輯和資料存取是可實作的。
ASP.NET MVC
針對原本ASP.NET對於MVC的架構支援的不足，微軟官方提供了ASP.NET MVC框架。於2009年3月19日正式發布，新的2.0版本也在測試中。
在新的ASP.NET MVC框架中，表現層與業務邏輯層的關聯進一步剝離，但是由於正處於發布初期，因此尚有許多問題沒有很好的解決。
Windows Forms
在WinForms中，這個針對檢視（View）和控制器（Controller）的模式已經很好的定義好的。而模型（Model）則留給開發者去設計。
- 外皮（View檢視）
- 由Form或者Control類繼承來的一個類處理檢視的職責。在WinForm這個例子中檢視和控制器被編譯在同一個類中，這個和ASP.NET不同。
- 筋（Controller控制器）
- 控制器的職責被分割成三部分。事件（Event）的產生和傳輸是作業系統的一部分。在.Net框架中Form和Control類將不同的事件轉發給相應的事件處理器。而事件的處理則在分離的代碼中實作。
- 骨架（Model模型）
- 就像ASP.NET一樣，WinForm不嚴格需要一個模型。開發者可以自行選擇建立一個模型類，但是很多人選擇放棄這一步，直接把事件處理放在控制器里處理任何計算、資料保存等等。也就是說用模型來包含商業邏輯和資料存取。