問題分離，業務邏輯與表示邏輯

在MVC中或者一般情況下，當試圖從視圖中分離業務邏輯時，在從視圖中刪除邏輯方面，你走多遠？視圖是否應該具有零邏輯？是否應該有多個靜態視圖以及變量填充的簡單「洞」，或者我們是否可以有一個視圖根據情況輸出不同的html？問題分離，業務邏輯與表示邏輯

<html> 
    <body> 
     <h1>Your name is @uname</h1> 
     @if(account<3000) { 
      <p>You are an ok customer</p> 
     } else { 
      <p>You are a great customer</p> 
     } 
    </body> 
</html>

以上是OK還是應該有兩個視圖，一個用於OK客戶，另一個用於優秀客戶？

來源

2012-10-11 Fergal

在視圖中有一些基本的邏輯就可以了，只要它只關心顯示的數據的顯示即可。我可能會改變你的例子，刪除「好」或「好」客戶的定義，並在模型中進行更早的設置。

如果account<3000應該在您的業務邏輯中定義，那麼可能是 - 模型或業務層，可以在其中進行單元測試和重新使用。然後，您可以使用客戶狀態枚舉在視圖中的標記執行此開關：

if (@Model.CustomerStatus == CustomerStatus.Ok) 
{ 
    <p>You are an ok customer</p> 
} 
else 
{ 
    <p>You are a great customer</p> 
}

來源

2012-10-12 12:51:14

有一個額外的觀點是錯誤的，在我看來，因爲它會導致你在許多情況下，複製HTML代碼。

對於您提供的示例，我會堅持在視圖中使用if..else塊，最終只有一個<p>，並將其文本設置爲變量。像

@string text = account<3000? "you are ok":"you are great";    
<p>@text</p>

當然，還那裏有另一種解決方案：用ViewModel類，這將有TypeOfCustomer字符串屬性擴展模型，與此相關的文字。總結起來，我不認爲它的「非法」在視圖中有這樣的塊，以設置正確的html。只要案例之間的差異小於共享代碼，那麼使用if..else塊來處理一個視圖就沒有問題。

來源

2012-10-12 12:53:15 YavgenyP

你究竟是什麼意思*「用viewmodel擴展模型」*？ –

與你做的事情完全一樣，可能是：創建一個新類，可能繼承他的基類（User？）或包含它，並將相關文本作爲屬性訪問，其值根據帳戶值設置。 – YavgenyP

在傳統的MVC實現中，視圖將包含表示邏輯。 MVC設計模式由兩層構成：模型層和表示層。視圖和控制器構成了表示層的大部分，控制器處理用戶交互並查看用戶界面的處理。因爲你實際上不能（很好......你可以，但在實踐中它是半不可能的）爲web應用程序實現經典的MVC模式，在ASP.NET MVC框架中，你通常有兩種方法來處理這個問題：

Rails-like：您將控制器中的表示邏輯推送出去，幾乎沒有邏輯模板。但我會坐下來，這是一個不好的選擇，因爲issues與軌道實施。
ViewModels.此結構允許您將表示邏輯與控制器分開。它實際上有點錯誤，因爲如ASP.NET MVC文檔中所述的ViewModels實際上是經典視圖應該是的。您將演示邏輯放入ViewModel實例中，並將您的「視圖」用作模板，該模板現在可以包含儘可能少的演示邏輯。

來源

2012-10-12 12:54:59

不管你的技術層面如何，你基本上說的是客戶如果他們的賬戶少於3000，那麼他們是好的，否則他們會很棒。

所以CustomerState（交換這一點有一個更好的詞，AccountState?）可以是Good或Great。

State因此是Customer的一個方面，應該是Customer上的財產/方法。

來源

2012-10-12 13:03:15

問題分離，業務邏輯與表示邏輯

回答

相關問題