Proper MVC question

[eluser]Maglok[/eluser]
I am developing an app that is growing quite big and I am stumbling upon a problem.

The MVC model is easy in concept: You have a Model, View and Controller.

I am just going to sketch a situation here and then ask a few questions about it that have been nagging me as of what is proper to do.

Controllers
- Person
- Event
- Signup

Views
- AddPerson
- EditPerson
- AddEvent
- EditEvent
- AddSignup
- EditSignup

Models
- Person_model
- Event_model
- Signup_model

The model classes would have for example 'add_person', that adds a person to the database. The Person controller would load the model and insert it, no problem there.

If you want the EditPerson view to show a list of Persons you'd load the model in the controller and then pull up get_all, pass that to the view, which displays it.

Now for the confusion. Lets say the models conform to the tables in the database and we have thus a person defined by a person_id, a event defined by a event_id and a signup defined by a signup_id. A signup would in addition be by a person for an event and it would thus contain a person_id and a event_id. Now lets say we want to display a list of the signups for an event and by name of the people participating.

This would require a query that spans all three tables. Tricky. Also it is for displaying purposes, hmm.

Questions
1. If you pull data from more then one table, what model do you put it in? (For 'proper' MVC)
2. If you pull data for display purposes do you pull it in the view or in the controller?
3. If you pull data for display purposes, do you even want a model function or do you just improvise a db query in the view? To me it has always seemed the MVC model means 'do not call the dbase unless it's from a model', so you can easily abstract that and all.

This is just an example, reality is much more complicated.

[eluser]bigtony[/eluser]
[quote author="Maglok" date="1248266540"]
1. If you pull data from more then one table, what model do you put it in? (For 'proper' MVC)
[/quote]
From your example, Person and Event are foreign keys in the Signup model, hence I would be putting the db join code in the signup model function(s).

[quote author="Maglok" date="1248266540"]
2. If you pull data for display purposes do you pull it in the view or in the controller?
[/quote]
Use the controller to call the signup model function (where the model is doing the join, as above) and pass the result set to the view.

[quote author="Maglok" date="1248266540"]
3. If you pull data for display purposes, do you even want a model function or do you just improvise a db query in the view? To me it has always seemed the MVC model means 'do not call the dbase unless it's from a model', so you can easily abstract that and all.
[/quote]
I think db calls should always be done in the model, which are called by the controller and then passed to the view.


That's my approach - but I *think* it's correct. :cheese:

[eluser]Maglok[/eluser]
1. Righto, makes sense.
2. Also makes sense.
3. Ah but then won't you have specific functions in your model to display data in a certain way? Since a dataset that grabs the names of an event and a person then puts them with a signup and passes that on is quite specifically made for displaying that data in a way specific to that view.

[eluser]bigtony[/eluser]
[quote author="Maglok" date="1248268824"]
3. Ah but then won't you have specific functions in your model to display data in a certain way? Since a dataset that grabs the names of an event and a person then puts them with a signup and passes that on is quite specifically made for displaying that data in a way specific to that view.[/quote]
The model functions to retreive data are for just that, to retrieve raw data (the rows, colummns and sort order you specify). That raw retrieved data is then passed to the view to sort out how it should be displayed.

I do understand the point you are making, but as far as the model function is concerned all it is receiving is a request to "give me such and such data sequenced in this order..." - the model neither knows nor cares how it will be used. What I often do is define an optional parameter on the function call so that the sorting column(s) can be specified, or if not it uses a default sorting column.

But if you think about it, even if you only have one simple table and a single function to retreive all the data from it it's still going to give you certain rows & columns in a certain order. All we are doing is adding extra columns through joins and specifying the sort order. The view is still completely separated.

[eluser]Maglok[/eluser]
True, but then my model just gets a lot of 'pollution' from functions that retrieve certain data sets, there has to be a more efficient way. I see your point though.

[eluser]bigtony[/eluser]
[quote author="Maglok" date="1248276595"]True, but then my model just gets a lot of 'pollution' from functions that retrieve certain data sets, there has to be a more efficient way. I see your point though.[/quote]
If you discover it, tell me... :-)

But I wouldn't really think of it as pollution but rather just a number of interfaces into a dataset. So you might have the following functions in your model:
get_signups_by_person()
get_signups_by_event()
get_expired_signups()
etc.

Inside the model each of the above could call a private method;
_do_query($where, $order_by)
just passing in the appropriate conditions, etc. So you don't even have to have duplicate code, as the private method constructs the query.

Also, when you call the public functions in your controller you can tell at a glance what it does from its name without having to worry about the internals.