我有一個關於MVC的問題。特別是關於模型。 假設我在我的數據庫中有一個類別表。現在我想要獲得一個單一類別的詳細視圖和多個類別的結果。另外，我可能需要針對不同目的查詢多個類別。多個模型vs單個模型
現在的問題是， 擁有兩個獨立模型會更有意義嗎？類似於單個類別上的操作的類別模型和多個類別上的類別模型操作。
我的想法是，當我使用category模型我不需要多個類別的額外細節。所以分開這些對我來說很有意義。但我不確定。
任何想法？
這取決於你需要保存不同的數據單個類別和多個類別？
如果是這樣，，你的建議是有道理的，否則你會在你的模型中有冗餘字段。我建議在兩種型號之間作出明確區分（所以不要Category和Categories，但例如SingleCategory和MultipleCategories）。
如果不是，我會建議有一個類別的模型，但爲單個和多個類別操作定義不同的操作。我認爲這是你的情況。
在後一種情況下，您可以使用抽象超類Category，然後定義兩個子項：一個包含單個類別的操作，另一個包含多個類別的操作。
問題是你的模型應該支持處理單個和多個記錄查詢。
所以我的建議是使用一個模型並開發您的方法來檢索您需要的確切數據。
有兩種模式單一數據源只是複雜的東西...
我不同意這一點，我認爲這個問題的重點已經錯過了。首先，無論您的模型是否包含查詢數據庫的邏輯，這都是設計選擇。某些用途選擇將邏輯與buiness對象（數據模型）和返回列表或單個業務對象的數據適配器/服務分開。無論哪種方式，重點是所提出的第二個對象不會重複任何事情，它只是通過存儲單個實例模型的集合和一些其他屬性來重用該集合的信息來重用現有模型。這是個好主意 –
我看不出有任何理由對同一個數據集合使用多個模型。
在MVC中，模型表示數據的集合 - 它可以是單個或多個項目。如果具體模型僅表示單個項目，它仍然是數據收集的一部分。
你爲什麼想知道使用兩個獨立的模型？
這隻取決於你！
你是程序員，無論你適合什麼。
但是添加我的推理：
單個模型類會更好的可讀性和可維護性方面！
例如
class get_fruits
{
function all_fruit(){}
function one_fruit(){}
}
這將是很容易讓其他程序員閱讀代碼來了解
例如
$get = new get_fruit();
$europeanfruits = $get->all_fruits("European");
$apple = $get->one_fruit ("Apple");
希望這有助於！
記得有沒有對錯的解決方案只是作爲aslong它的工作原理爲您服務！
在我看來列表，數組，集合等，這些由你所使用的語言提供的是模型集合有效的選擇，你不應該創建一個簡單的包裝這個集合的附加模型，因爲它確實沒有達到在所有。如果您想將某個接口與集合相關聯，則可以考慮將該集合包裝在模型中。
如果你特別需要存儲關於收集更多的信息，那麼你應該在另一個模型包裹。
我也不同意，你不應該有多個型號，因爲數據來自同一數據源的想法。事實上，我相信你不應該把你的數據庫邏輯放入模型本身，而是使用一個單獨的服務來返回業務對象。這種封裝級別允許您在應用級別上操縱高級模型（或業務對象），同時將數據訪問邏輯與這些對象分離。如果您隨後需要使用其他方法替換數據庫，則只需要替換數據訪問邏輯和創建模型的接口即可。
我們在我們自己的MVC和ORM所做的是，我們創建了一個包裝，以便在多個模型實例操作。哪一個是ResultSet。結果集然後能夠對例如類別模型的數組執行操作。
「現在我想問題，無論是細節的單一類別」是沒有意義的。你能修好嗎？ –