Multiple models vs single model

Question

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?

Selftaught

"Now I would like to questions both a single category for details" does not make sense. Can you fix please? – Gastroscope

Answer 1

It depends, do you need to save different data for a single category and for multiple categories?

If 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.

Errecart

Answer 2

The thing is that your model should support handling single and multiple record queries.

So 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...

Embrasure

I disagree with this, I think the point of the question has been missed. First off it's a design choice whether or not your model contains the logic for querying the database. Some of use choose to separate the logic with buiness objects (the data model) and data adapters/services which return lists or single business objects. Either way the point is that the second object being proposed does not duplicate anything, it merely reuses an existing model by storing a collection of single instance models and some additional properties for information about that collection. This is a good idea imo – Atronna

Answer 3

I can't see any reason for using multiple models for the same collection of data.

In 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?

Octant

Answer 4

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.

For reference: https://github.com/Tuxion/tuxion.cms

Someone

Answer 5

It just depends on YOU!

You 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!

Pettifog

Answer 6

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.

If 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.

Atronna