new to CI / MVC in general ... few questions :T

[eluser]Unknown[/eluser]
Hey guys,

As $title says, I'm new to this new formatting approach of MVC (though not programming), so I'm a bit confused as to some of the stuff. I'm finding it a little hard to put my question in words, so please bear with me a bit here.

Basically, some parts of the MVC design in general are not making sense to me. I can't really see a practical example of what a Model should be. Or, more specifically .. should I ever use a Model just to access a DB table, or would you do all of that in a view?

A sample scenario I'm thinking of is where you just have a database table that you are reading from and accessing directly. The DB and ActiveRecord functions are quite nice, and make it incredibly simple to read and write data, updating the table records as necessary. I guess that's my question ... if you just need to edit stuff in and out of data rows, would you use the View (fex: parse $_POST from an update form, and set the new data to the variables)?

I can understand using a Model if you need to take a high level approach to a complex database schema, where you don't want to rewrite long queries w/joins and such, but that's the only time I could see using it.

I'm curious what people are using Models for, exactly, or .. how basic of a level they should be applied.

Thanks

[eluser]skunkbad[/eluser]
You don't have to use models. I say that because it's true, as you can put everything in the controller if you desire. The user manual even suggests this. I use models for DB queries, inserts, updates, etc. I also may process the result or result array of a query in the model, before sending it to the controller. I load my views from the controller.

I think some people's work flow is totally different. I think some people load the views from the model, and they have the model do almost everything, with the controller just handling input.

Unless you are going to work with other people, it really doesn't matter what you do.

[eluser]Barry Cogan[/eluser]
The goal behind models is they do all the work. Be it fishing data from a table, handling file uploads, etc.
The controller just tells the model and view what to do. It will take the information, get the model to do some work on it then pass it to the view.

This means that when you come to look at your code some time from now you will be able to take one look at the controller and know what is meant to be happening.

The other benefit to models, lets say in terms of your accessing the same DB table. You need only write the one function and call it however many times you want instead of copying it from function to function within the different controllers. that re-usability is where the real value of models comes in.

So for your specific case I would use a C.R.U.D. model for each database table. It seems like the best use of models for you.

Hope that helps

[eluser]leonardteo[/eluser]
Depends how big your site is. If you're doing something really simple where one controller only works with one set of data, then you can get away with not using models. It is generally good practice, however, to stay to MVC and to keep data calls in the model. As your site grows and you need the model to be accessed from other parts of the application, you won't have redundant code that you put in controllers. You simply lead the model from the respective controller. It is really about modularizing code so that it can be re-used.


L.

[eluser]Unknown[/eluser]
Thanks for the feedback guys.

In an ideal scenario, would you have an existing Model for each database object you wanted to access?

[eluser]leonardteo[/eluser]
Again it depends on the application and how you want the data to be accessed. Essentially, the Model should just be a logical representation of how an application needs to read and write data.

Take, for example, a User profile. You may have a number of tables that make up all the data for the user, e.g. a User table and Userfields (for custom fields), joined by user_id -- (incidentally, this is how VBulletin works). Under certain circumstances, you only need to fetch data from the User table but other times you want it joined with Userfields. Because the Userfields data object is kind of 'additional', one doesn't need to create a data model for that. The model needed is just User, and you write the functions that does the joins as needed.

L.