ASP .NET MVC架構如何適應傳統的多層架構

Question

從傳統的Web應用程序架構方法（包括業務層，服務層，數據訪問層和表示層）轉向MVC設計模式，我發現很難理解它如何適應舊模型。

似乎MVC模型本身已經完成了分離關注點的分離，這些問題需要通過分層架構來實現。 有人可以對這個問題有所了解嗎？

作為參考，以下是我的理解，請分享您對此的看法

MVC視圖和控制器以及視圖模型 - 表示層

MVC模型 - 可以是 - 數據訪問層或業務層甚至服務層

Answer 1

我將Asp.Net MVC部分僅視為整個應用程序的視圖（或演示文稿）部分 。

我也在努力解決如何以適當的方式構建應用程序的問題。
按照我在這里聽到的洋蔥架構 （特別是這里的圖片），我的解決方案看起來像這樣：

• Project.Core
  業務邏輯/服務實現，實體，必須由其他項目實現的接口（即“IRepository”，“IAuthenticationService”，......）
• Project.Data
  數據庫連接 - 在我看來，NHibernate存儲庫和實體映射都在這里。 實現Project.Core的數據接口
• Project.UI.Web
  Asp.Net MVC（“演示”）項目 - 它將整個應用程序連接在一起。
  在Project.Core中實現接口的實現，並將它們（以及來自Project.Data的那些）與一些DI框架（如Castle Windsor）連接起來。

Project.UI.Web遵循以下約定：

• 它的模型只是（！） viewmodels
• 視圖使用自己的視圖模型 （one-view-one-viewmodel）
• 控制器只需要驗證輸入， 將其轉換為域對象 （因為業務邏輯對於視圖模型一無所知 ）， 並將實際工作（業務邏輯） 委托給業務服務。

摘要：
如果您遵循此模型，那么關注Project.Core是有幫助的： 這是真正的應用程序 。 它不擔心數據的真實持久性，也不關心它是如何呈現的。 這只是“怎么做”。 但它正在規划其他項目必須提供實施的規則和合同（接口）。

我希望這可以幫助您如何布局Asp.Net MVC應用程序！

LG
warappa

Answer 2

正如其他人所說，它沒有太大變化。 我的應用程序通常是這樣構建的：

• 模型層（域和視圖模型）
• 存儲庫層（數據訪問）
• 服務層（有時根據應用程序/要求實現為WCF服務）
• 服務器端MVC層（Asp.net MVC本身）
• 客戶端MVVM或MVC（通過Knockout.js，Backbone.js或Spine.js）

在服務器端MVC層，我的控制器方法非常輕。 他們通常在服務層對象上調用一個方法來獲取一些數據，並將其作為Json數據傳遞給客戶端。

因為我要把Json送回去，我的觀點也非常輕盈和稀疏。 通常只包含腳本包含和將使用客戶端模板庫呈現的模板。

Answer 3

簡而言之：沒有太大變化。

我只熟悉一些演示模式：MVP（模型，視圖，演示者，Windows窗體/ asp.net中常見），MVC（模型，視圖，控制器）和MVVM（模型，視圖，視圖模型，常用於WPF / Silverlight的）。

鏈接： http ： //haacked.com/archive/2008/06/16/everything-you-wanted-to-know-about-mvc-and-mvp-but.aspx

上面的鏈接應該回答你的一些問題（如果不是全部的話）。

我通常編寫ASP.NET MVC應用程序的方法是至少包含一個用於CRUD操作的服務/業務層混合（因為數據訪問既不屬於視圖模型也不屬於控制器，絕對不屬於視圖！）。

Answer 4

非常基本的解釋：

如果您創建一個新的MVC應用程序，您將自動獲得一個Controllers，Models和Views文件夾。

您的控制器就像您的業務層一樣
模型是數據訪問/服務層
和視圖是表示層。

有關詳細說明，請訪問http://www.asp.net/mvc 。