我一直在想的東西，但有點太尷尬，直到現在要問：在「正確的」MVC（嚴格遵守模式），是否一切都必須是模型，視圖或控制器？如果不是的話，你能舉一個例子說明什麼時候打破模式是明智的或必要的？最後，MVC中類（或靜態）方法的作用是什麼？在適當的MVC中，一切都必須是模型，視圖還是控制器？
具體示例：我有型號OneModel和TwoModel。沒有任何理由認爲它們是從一些超類繼承而來的。兩者都有完全不同的屬性，但它們確實共享一個emailAddress字段，我希望有時爲每個模型分配validateEmailAddress()。我不想複製每個模型中的驗證代碼，所以我使用類方法制作了類，我現在將在OneModel和TwoModel中分別調用該類。
我現在打破了模式？我該如何解決它？
如果你看到模型，視圖和控制器的應用層，而不僅僅是表現層的成分，那麼你的電子郵件驗證類將是模型層的一部分，因爲它包含業務邏輯。我沒有看到你打破模式的地方，並不是每個模型類都必須是一個數據對象。
「嚴格遵守模式」的問題在於模式隨着時間的推移而發展。原始模式用於單用戶應用程序的GUI。後來它適應了網絡，但有不同的解釋，特別是模型和控制器之間以及客戶端和服務器之間的責任。因此，準備在沒有一個「真實」的情況下得到不同的答案。
對我來說夠好...謝謝！ –
我不想把它打破給你，但MVC並不意味着「我的代碼」。雖然SoC原則的應用可能會有所不同，但核心責任保持不變。 –
MVC設計模式是由兩個主要部分組成：
表示層提供了一種用戶與模型層交互，而模型層包含所有的業務邏輯和相關的任務。
模型不是類或對象。相反，它包含幾組結構，每個結構都有不同的領域業務邏輯方面的職責。你可以閱讀更長的解釋here。
表示層主要根據它如何與模型層進行交互來劃分。你可以說控制器「寫」到模型層（通過服務）並且從它讀取「讀取」。
整個MVC設計模式（以及其他MVC啓發模式）中最簡單的部分應該是控制器。他們接受用戶輸入並基於該改變模型圖層的狀態。他們也可以改變視圖，但是，當MVC應用於網絡時，它更像是一個例外，然後是一條規則。
至於意見 - 我仍然試圖找出它們。我目前得到的可以讀取here。
注：有一個嚴重缺乏材料的有關實施意見，當應用到Web上。由於該平臺與桌面應用程序完全不同，因此不可能直接移植相同的指南。我還沒有發現任何關於這個主題的與框架無關的材料，這些材料專注於爲Web創建視圖。
我傾向於以略微草率的方式思考視圖：視圖是負責顯示內容的任何東西。因此，在使用模板時，您的模板就是視圖，當您使用生成界面元素的框架中的類時，這些視圖也是視圖的一部分。 無論如何，重要的區別在於表示層和模型層之間的區別。 – confusopoly
@confusopoly，模板不是視圖 –
就像我說過的，我以sl way的方式思考這個問題。 – confusopoly
您必須瞭解MVC是一個架構模式。因此，這是一個更高層次的模式，它描述了組件的組織方式和彼此之間的交互。爲了實現這個組織，你將需要一套專門的組件來完成你的「骯髒的工作」。在這個集合中，可能會有一些組件不符合任何字母M-V-C的定義，一些組件只是在幫助功能，其他組件則在這些層之間的接口上，從事它們的集成。
所以，答案是沒有，不是everthing是模型，視圖或控制器。
做到這一點的一種方法是定義一個包含地址和驗證邏輯的類EmailAddress。然後，如果你想給它自己的視圖，你可以用它來顯示它。 – confusopoly
EmailAddress是一個模型嗎（例如'OneModel'和'TwoModel' *在DB中有'EmailAddress'）還是隻是普通的老類？ –
從您的UI代碼的角度來看，它將充當模型。這仍然只是一個普通的老班。 – confusopoly