When to use Models ? (just need a little briefing)

[eluser]sikko[/eluser]
Hi all,

I've watched the two video tutorials but they don't explain when should we use models...
In the blog application for instance ? why don't even we use models ? Aren't they needed ?

If you take a look at [email=http://video.derekallard.com/]this sample application[/email], you will notice that the guy uses a model with only one function:

Code:

function getSearchResults ($function_name, $description = TRUE){
//the function...
}

Why haven't he put this "getSearchResults" function in the controller ?

Thank you for your help.
//CI Rocks!

[eluser]John Pantoja[/eluser]
Because Tom Cruise deems it so lol

Well, common sense (which I lack) say due to CI following the MVC concept, the M being Model. The reason to use a model it for aesthetics, code organization and many others. Having a model allows you to loosely couple your CRUD from your business logic. I can tell you from experience, it sucks having to track down all of your code that does database interaction, especially when it's sprawled out. You're bound to forget to update a query and it will be the client that discovers it and not you. Having a model allows you to put all of that code in one place.

Granted if all you have is one or two queries, it may be a pain to have a model, but show me an app that doesn't have at least four or five queries? And with Murphy's law, something is going to change. By abstracting out your queries, the rest of you app is ignorant to this part and doesn't know or even care if the database has changed.

[eluser]Colin Williams[/eluser]
Models are the backbone of your application. MVC is discussed as a triad but it's closer to two layers than three. Models handle the main operations of your app (saving, retrieving, formatting/manipulating data) and Controllers work with Views to create the interface.

The controller is the decoupler. It decouples Views from Models and Views from other Views. I think it trips people up who are using it with Web apps because of URL mapping. It gives you the sense that since this URI maps to this Controller method, that the Controller is the big dog, so people start loading up their Controllers with a lot of Model code. But, just look at URLs (and HTTP for that matter) as nothing more than a way for Views to communicate with the Controller, as if you were just calling a function (and URI params and form data are your arguments).

[eluser]Myles Wakeham[/eluser]
[quote author="sikko" date="1264044055"]Hi all,
I've watched the two video tutorials but they don't explain when should we use models...
In the blog application for instance ? why don't even we use models ? Aren't they needed ?
[/quote]

Models are a necessity. Now in specific reference to your question, there's a simple reason and a more complex reason. Let's say that you build an app based on your data stored in MySQL. Then someone comes along and says to you, "Hey, can you support PostgreSQL?". The fact is that you need some layer of abstraction between your User Interface code (the controller & view) and your backend database (the model). If you use a Model to handle all interaction between your web app and your database, you can code it the way you want. If you put all your SQL in there for MySQL, then its a relatively simple process to code it so that alternative SQL for other databases can be supported. Or if you store data in flat files, you can handle that too.

The more complex (and I feel more attractive) reason to use models is that you get to take advantage of true 'black box' coding of what your application is really trying to do. A model is a great place to put all the 'transform' code that takes the user's interaction and converts to persistent storage. For example, if you have a Customer table in a database, you might want to ensure that if the customer has been bad and not paid their bills on time, that you have a single place to check if the customer is 'on credit hold' for any transaction that affects that customer. If all of your DB interaction goes through a Model, your problem is solved. Also you probably want to abstract the true nature of what your controller does without the complexity of being specific with the database. For example, the controller should be able to just ask "What's the account balance for this customer?" and get back a number. It should NOT ask "SELECT ACCOUNT_BALANCE FROM CUSTOMER WHERE CUSTOMER_ID = 123". That's just not maintainable, and if you change your DB schema, you'll be spending a month of Sunday's changing all of our code throughout.

You can take models to the extreme, or just use them to abstract your app from your database. But whichever way you use them, I find them to be a critically important part of the entire MVC architecture. Your mileage, of course, may vary.

Myles

[eluser]brianw1975[/eluser]
[quote author="sikko" date="1264044055"]Hi all,

I've watched the two video tutorials but they don't explain when should we use models...
In the blog application for instance ? why don't even we use models ? Aren't they needed ?

If you take a look at [email=http://video.derekallard.com/]this sample application[/email], you will notice that the guy uses a model with only one function:

Code:

function getSearchResults ($function_name, $description = TRUE){
//the function...
}

Why haven't he put this "getSearchResults" function in the controller ?

Thank you for your help.
//CI Rocks![/quote]

I'm going to quote a favorite band of mine: "You gotta keep 'em seperated!"

In the long run having all data controls in a model means easier re-usability over different controllers.

it also means easier maintainability. you only have to go somewhere once to fix a bug instead of 10 different controllers.