I have a question about MVC. Particularly about models. Suppose that I have a category table in my database. Now I would like to get results both for a single category for detailed view and multiple categories for a listing. Also I may need to query a number of categories for different purposes.
Now the question is; Does it make more sense to have two separate models. Like category model for operations on a single category and categories model operations on multiple categories.
My thinking is that when I am using category model I don't need additional details for multiple categories. So separating these makes sense to me. But I am not sure.
Any ideas?
Source: Tips4all
It depends, do you need to save different data for a single category and for multiple categories?
ReplyDeleteIf so, your proposal makes sense as otherwise you would have redundant fields in your model. I would advise making a clear distinction between both models (so not Category and Categories, but for example SingleCategory and MultipleCategories).
If not, I would suggest having one model for a Category, but with different operations defined for single and multiple category operations. I assume this is your situation.
In the latter case, you can make use of an abstract super class Category and then define two children: one that contains operations for single categories and one that contains operations for multiple categories.
The thing is that your model should support handling single and multiple record queries.
ReplyDeleteSo my advice is to use one model and develop your methods to retrieve the exact data you need.
Having two models for a single data source only complicates stuff...
I can't see any reason for using multiple models for the same collection of data.
ReplyDeleteIn MVC, model represents collection of data - it can be single or multiple items. If specific model represents only single item, it's still the part of collection of data.
Why are you wondering about using two separate models?
What we did in our own MVC and ORM is that we created a wrapper for operations on multiple model instances. Which is a ResultSet. The resultset then is able to do operations on for instance an array of Category models.
ReplyDeleteFor reference: https://github.com/Tuxion/tuxion.cms
It just depends on YOU!
ReplyDeleteYou are the programmer whatever suits you is what goes.
However to add my reasoning:
A single model class would be better in terms of Readability and Maintainability!
e.g.
class get_fruits
{
function all_fruit(){}
function one_fruit(){}
}
This would be very easy for another programmer reading the code to understand
e.g.
$get = new get_fruit();
$europeanfruits = $get->all_fruits("European");
$apple = $get->one_fruit ("Apple");
Hope this helps!
Remember there is no right or wrong solution just aslong as it works for you!
In my opinion lists, arrays, collections etc. which are provided by the language you are using are valid choices for collections of models, and you should not be creating an additional model that simply wraps this collection as it really achieves nothing at all. You might consider wrapping the collection in a model if you want to associate some interface with the collection.
ReplyDeleteIf you specifically need to store additional information about the collection then you should wrap it in another model.
I also disagree with the idea that you shouldn't have multiple models because the data comes from the same data source. In fact I believe you shouldn't be putting your database logic in the model itself, but using a separate service that returns business objects. This level of encapsulation allows you to manipulate the high level models (or business objects) on the application level while decoupling the data access logic from these objects. If you then need to go and swap out the database with something else, you need only replace the data access logic and the interface that creates the models.