Asp.net MVC是否有助於創建n層解決方案？

它確實將用戶界面的邏輯和數據分離開來，但它仍將它們全部組合到單點應用程序中。
這就是爲什麼我認爲它不是真的，因爲控制器是業務邏輯，視圖是UI，模型是DAL。這些現在只是同一個應用程序中的圖層。

但是圖層應該是第一個還是第二個要實際調用的品種圖層？

任何人都想自己添加2美分？

2009-06-03 Robert Koritnik

「crams」是不必要的情緒，另一個視圖（我的）可能是這些組件實際上是清晰和清晰地劃定的 - 只要這些組件是正交的，這些線是任意的 – annakata 2009-06-03 08:17:48

控制器應該不包含業務邏輯 - 這是模式的作用湖模型背後的內容可能是多層次的，也可能不是按需要的。 MVC實質上是一種UI模式。 – dice 2011-04-29 14:49:00

MVC模板項目只是爲了讓你開始 - 你可以很容易如果你想要將控制器和/或模型移出到單獨的項目，並且它在你的應用程序中有意義。請記住，對於可能有三個控制器的小應用程序，模型層中的幾個額外類以及EF或LINQ數據模型，您確實沒有足夠的文件來證明分離到不同的項目中。

來源

2009-06-03 00:17:20

那麼，我的生日蛋糕有層，但它仍然是一個大蛋糕...所以是的？

來源

2009-06-03 00:15:39

當然它！

我認爲兩種觀點並控制器包含用戶界面邏輯......業務邏輯應該在模型（這不僅是DAL）。

作爲您可以使用的模型，例如， CSLA objects並根據需要添加另一對物理層（通過配置）。

你要知道有邏輯層和物理層（或層VS層）之間的區別...

上有lhotka的網站很多有趣的文章關於這個話題！
例如this one和this one。

來源

2009-06-03 08:46:08 fretje

圖層和層可互換。在n層的情況下，你可以稱它爲表示層，但在分層應用程序的上下文中，你可以稱之爲表示層。但他們真的是一回事。

n層應用程序和鬆耦合的石蕊試驗是，如果可以採取各層次的和他們建立爲單獨的項目和在不同的機器部署它們。

爲n層應用程序的關鍵區別是關注（SOC）和低耦合的分離。一個真正解耦的應用程序可能是一個只包含純HTML的層次的應用程序。然後是另一個包含純Javascript的應用程序，並使用AJAX更新DOM並與Web服務進行通信。 Web服務包含它自己的一套層。

Web服務都有一個路由引擎，將請求路由到不同的控制器。控制器會清理和解釋請求，驗證認證以及哪些不適用，並調用適當的模型。模型反過來必須返回POCO對象或DTO，並將它們返回給注入DOM的Javascript。 Javascript可能會修改對象並將其發回並保存到數據庫中。實體框架4。0對這種n-tier scenarios有很好的支持，儘管它在SoC部門中確實有些短暫（例如，強類型化視圖），但對於更多目的而言它是實用的。

MVC Futures我相信支持一些開箱即用的控制反轉（IoC）容器，目前如果您想要鬆耦合和真正的n層場景，您可能需要使用您選擇的IoC容器。

來源

2009-06-03 08:58:40 aleemb

我不認爲控制器是商業邏輯。它們是應用程序邏輯，將業務邏輯（模型）和表示邏輯（視圖）結合在一起的粘合劑。

來源

2009-06-03 08:59:31 DSO

您不認爲業務邏輯（如業務流程中）不是*模型的一部分嗎？模型僅僅是業務流程的數據存儲區... – 2009-06-03 09:15:45

「層」通常是指不同的物理服務器，而「層」是指將功能分離爲鬆散耦合的區域。

即，3層網絡應用程序：第1級）DB服務器第2級）的Web服務器第3層）的客戶端瀏覽器

3層網絡應用程序：層1）UI 第2層）商業邏輯第3層數據訪問

來源

2009-06-03 21:07:41

Asp.net MVC是否有助於創建n層解決方案？

回答

相關問題