編輯：感謝您的回答。他們是有幫助的。我的最後一個問題是，是否可以通過REST執行此操作？MVC與第3層接口的模型
首先，我意識到這些已經被有點在以下兩個鏈接中回答，所以請不要將其作爲副本關閉。我是合法的困惑！
據我所知，MVC設計是在3層架構的「表現」層，允許創建GUI。我明白了。然而，我感到困惑的是GUI中的數據模型應該如何與「第2層」應用程序邏輯交互。這是怎麼了預想它：
所以從我收集，每當用戶與GUI交互，並更新模型，是模型的責任，然後再跟的休息通過Web服務器API的架構？
您的控制器包含輕量級應用程序邏輯，這是在模型和視圖之間協調工作所需的。例如，您的控制器有責任讓從業務/數據源的數據，並將得到模式映射成是給你的視圖一個視圖模型。
視圖還應包含儘可能少的邏輯。由於視圖模型是專門爲視圖創建的，視圖的唯一責任是使用視圖模型的數據進行自身渲染。
您所指的模型確實是您從後端獲得的結果。如果您直接訪問數據庫，它可能是WCF服務返回的代理實體，Web API返回的數據實體或實體框架對象（全部取決於您要使用的架構）。這個模型然後用來構建一個視圖模型，你的視圖用它來自我渲染。
取決於你想如何構建你的項目。
例如：有時我們不想公開我們的模型類（實體）。所以，我們創建DTO類來接收來自UI的信息，這些信息將由控制器處理，並將它們傳遞給將它們轉換爲實體的業務邏輯。它在SOA解決方案中使用了很多，我們可以揭示我們的服務。
示例：UI請求 - >具有DTO的控制器 - > BLL（轉換爲真實模型類） - > Repository/DAO - > DB。
關於等級的討論與MVC的討論確實是正交的。
MVC並沒有真正談論模型應該如何與外部服務/數據層交談。有關於它的一些很好的討論here。關於數據訪問/持久性是否應該在您的模型層或您的控制器層中存在爭議。我更喜歡它在我的模型層。
我也比較喜歡Anemic Domain Model，所以我傾向於將實際談話放在模型的服務部分的DAO圖層中，而不是域對象。但是將其放入模型對象中也很有效，您只需要使用DAO模式將持久層與業務邏輯層分開。
問題是，您的兩層都需要自己的型號和他們自己的DAO層。 Presentation Tier的DAO層將與Business Tier進行交流。業務層的DAO層將與您的數據庫/存儲層進行對話。
這會將每層與其他層中的更改隔離開來。