商業邏輯是否應該在模型中？ （MVC4）

Question

我在我的MVC應用程序中有一個名爲「Stores」的類，它有一個名爲「IsInCompliance」的類，它依賴於其他幾個字段的值。邏輯會通過並說「如果這，這，這是真的，那麼IsInCompliance是真的」。

這應該屬於模型定義中，還是將這種邏輯放置在服務層或控制器中？我想我有四個選項：在模型中包含的方法

1. 邏輯包含在一個控制器
2. 邏輯寫回模型包含在服務
3. 邏輯模型調用
4. 控制器呼叫的服務中包含的邏輯

哪個最好？如果3最好，那裏沒有循環依賴（因爲我的模型項目取決於服務項目，這取決於模型項目）？

Answer 1

4號是正確的方法。控制器應該作爲一個薄的「流量控制」層，並將所有邏輯委託給它們下面的服務層（或者，如果它不是太明顯的邏輯，就是業務層 - 但這是一個不同的體系結構問題）。

您的模型通常應該是一個純粹的POCO結構，可選地包含數據模型內部的微邏輯。例如，ID生成和數據完整性操作。

你的大部分邏輯（對於相對簡單的/基於CRUD的應用程序）通常應該駐留在服務層中。

Answer 2

這是一個偏好/風格問題，但我始終認爲與Model對象密切相關的方法屬於該對象。

拿這個作爲一個例子（我編碼在飛行中沒有一個開放的VS.NET的實例，所以請原諒任何語法錯誤，只是想以此作爲交流的載體）：

public class Person 
{ 
    public Int32 Age { get; set; } 

    public bool IsEligibleToEnterLegallyBindingContract() 
    { 
     return Age >= 18; 
    } 
} 

我會斷言模型對象包含反思自己的屬性並且不依賴於消息和/或其他模型對象的屬性的方法是良好的對象設計和MVC環境中的良好建模方法。

更新我和一位同事討論過這個問題，他指着我走向了由Martin Fowler撰寫的優秀文章Anemic Domain Model。在我的同事推薦它之後，我多次閱讀這篇文章。

從福勒先生的文章最後一段（這是從martinfowler.com和信貸的直接報價被確認，並給該網站）：

「在一般情況下，更多的行爲，你的服務發現，那麼你越有可能搶奪領域模型的好處，如果你所有的邏輯都在服務中，那麼你就會失明。

Answer 3

MVC是關於分離問題。保持這種方式。將業務邏輯放置在單獨的類（層）中，從而將邏輯與數據分開。

Answer 4

通常我會在模型上執行操作而不是在模型中執行操作，但它是一種個人偏好。 我會（在你的情況下）在服務層中寫入邏輯，然後從控制器上進行一個協調調用，該調用將在模型上工作。然而，這說，我相信有人將此稱爲Anemic Domain Model。

我不認爲任何的方法是錯誤的，但我個人會去數4

Answer 5

我想這取決於你的編碼風格。

根據您的要求，選項1或選項4都是正確的。

對於這樣的事情，我認爲選項1是正確的。

如果IsInCompliance僅依賴於模型中其他屬性的值，那麼它應該在模型中。

如果IsInCompliance的值依賴於其他類，那麼是的，它應該在服務層。

移動這樣的東西在一個貧血的領域模型服務層的結果在您的模型類，最終只是成爲DTO的

在面向對象的設計，這被認爲是一個反模式。

仍然有很多東西需要在服務層，我只是不認爲這是其中之一。