對型號型號成員進行操縱的方法應該在型號或控制器上實現。這取決於這種操縱是多麼「沉重」？MVC - 除了set/get成員外，哪些方法應該在Model類中？
「操縱」我的意思是 - 得到一個班級成員，根據他做出長時間的計算，然後返回與該班級有關的另一個值。
例如 - 擁有Board class它擁有一個單元格矩陣成員，現在我想實現一種方法，根據特定的單元格位置返回所有周圍的單元格。誰負責執行上述？
如果這個問題屬於另一個Stack Exchange QA，歡迎發佈帖子。
你所說的「型號」實際上是domain objects。 MVC中的實際模型只是一個層面，而不是具體的東西。
在您的具體示例中，Board應該有一個返回此列表的方法。我認爲，你實際上正在獲得它，因爲你需要進一步與這些細胞進行交互。
這就是模型層中的services來玩的地方。如果使用它們，則它們是模型層的外部部分，幷包含應用程序邏輯 - 不同域對象之間的交互以及持久性（通常爲data mappers或units of work）與域對象之間的交互。
假設您正在製作遊戲，並且您和玩家執行AoE攻擊。控制器持有服務，負責此功能併發送命令：該播放器瞄準AoE在這個方向，執行它。
服務實例化
Board並要求周圍的目標位置的單元格。然後它對它獲取的集合中的每個單元執行「損害」。邏輯完成後，它告訴工作單元實例提交所有更改，發生在Board上。
控制器不關心什麼服務的細節。它不應該收到任何反饋。當執行進入視圖時，它從模型層請求最新的更改並修改UI。由於附加的好處 - 服務可以讓您停止業務邏輯在表示層泄漏（主要由控制器的視圖組成）。
域對象應該只包含處理它們狀態的方法。
保持你的控制器精簡，不要讓它們做太多，這符合面向對象設計的SOLID中的單一責任原則。如果你有胖控制器，他們很難測試和維護。
至於模型，我曾經有愚蠢的模型之前，沒有做任何事情，但映射到數據庫表，這是從網上看到的大多數示例應用程序的啓發，但現在我不這樣做。我試着遵循領域驅動設計的原則，其中模型（DDD術語中的實體）位於應用程序的中心，他們期望封裝與實體相關的行爲，他們是智能模型（所以是的，在這種情況下，與對象相關的邏輯將與它一起生活）。 DDD是一個更大的話題，它與MVC沒有直接關係，但它背後的原理可以幫助你更好地設計你的應用程序，如果你使用谷歌DDD，還有很多材料和示例應用程序可用。另外，Ruby On Rails社區 - 這似乎激發了大多數MVC框架 - 似乎也有圍繞Fat模型和Skinny控制器的炒作。
最重要的是，您可以添加查看模型到您認爲有用的組合中。在這種情況下，您可以使用ViewModel來表示模型的一個啞元子集，僅用於生成視圖，它使您的生活更輕鬆，並進一步將視圖與模型分開，從而不影響您的設計不必要的決定。
我認爲這與MVC無關，還有更多與常規軟件工程有關的事情。
我個人會毫不猶豫地在模型中堅持微不足道的計算，但會對脂肪模型非常謹慎。
現在，MVC代表模型視圖控制器的事實並不一定意味着的一切應該是視圖，模型或控制器。如果你覺得有必要將職責轉移到一個不符合M，V或C的單獨課程，我不明白爲什麼你不應該這樣做。
您實施它的方式取決於您。您可以使用這個單獨的類作爲「頂層」（缺少更好的術語）對象，或者使用模型委託給它的方法，以便隱藏您正在使用它的事實。我可能會去後者。
一切都有爭議，但。每個人和他們的姐妹似乎對如何做MVC權利有不同的看法。
我，我只是認爲它是一個指導方針。當然，這是一個好主意，因爲它可以讓你更好地分離關注點，但最終 - 因爲它總是發生 - 沒有一種適合所有情況的方式來應用它，而且你不應該被它過分地限制，所有事物都必須是視圖，模型或控制器。
根據最佳實踐，我們應該只使用計算字段的屬性來獲取訪問權限。示例public double TotalCost { 得到 { return this.Role.Cost * TotalHour; } }
你是什麼意思的「操縱」？也許幾個例子會有所幫助。 –
@ s.m。我在編輯中解釋了 – URL87
關於在哪裏將算法放在MVC項目中，這裏有一些有趣的線索。 [這是一個]（http://stackoverflow.com/questions/9376459/mvc-design-pattern）。請注意，這是一個稍微主觀的話題。 – keyser