Confused over the MVC pattern and the usage of classes

I've used the MVC pattern through Code Igniter for some time now. Since I'm not very experienced with OOP concepts it has become much procedural work, but now I want to expand my design pattern skills, but it is confusing me.

I'm not exactly sure how to use MVC with what I feel is more 'generic classes'. Say if I wanted to make a class that would handle input validation, would I then make this a library? If I then wanted to extend this library, would I just create a new class and save it in the library folder together with it's parent? Am I able to make a folder structure within the library folder?

I want to stray away from the mindset that a controller is what I need when I am making something new. Maybe one can think of it this way; If I make a search, and the search have several 'types/tabs', say search on users, pages, blogs and such, would I then make these different libraries that maybe extend some super library, and then just make a search controller to decide which of the classes to use for each task? So if a user goes to the 'Search blogs' tab the search-blog class would be loaded instead of just having a big bunch of procedural stuff?

Also, if it would be a good idea doing it this way, then why do I have models? I feel models are just like classes (well, they are duh) in a way. But why use custom classes/libraries if I can just use models instead?

Problem at hand: I'm getting sick of editing core functionality. I'm afraid of breaking the application, and it's getting very tiresome.

Thanks

Since I have been looking into MVC and OOP recently too, this may help (in context to what you have asked):

1. MVC architecture vs three-tier architecture

The Model-View-Controller (MVC) pattern separates an application into three main components: the model, the view, and the controller.

Model: Most intro MVC articles refer to the Model simply as the data or database part of the application. This isn't accurate. The Model is the part of your application that operates on your data, and also contains all the other logic or business rules of the application that isn't a part of the Controller or View. So most of an application's code will be in the Model classes.

Views: Views are the user interface part of the application with which a user interacts with the application. The UI is typically created from the model data.

Controller: The Controller handles all user requests (from a View) and responds to user input. It passes the user inputs to the Model, which may process it, and once an output is ready the controller will pick an appropriate view to display the output. The View may, as necessary, communicate with the Model to retrieve the output and parse it for the end user.

Both the View and the Controller communicate with the Model but are independent of each other and thus can be modified easily (this is the conceptual 'separation' in the MVC).

The MVC pattern is often confused with the three-tier architecture.

From wikipedia: "Three-tier is a client–server architecture in which the user interface, functional process logic ("business rules"), computer data storage and data access are developed and maintained as independent modules, most often on separate platforms ... At first glance, the three tiers may seem similar to the model-view-controller (MVC) concept; however, topologically they are different. A fundamental rule in a three tier architecture is the client tier never communicates directly with the data tier; in a three-tier model all communication must pass through the middle tier. Conceptually the three-tier architecture is linear. However, the MVC architecture is triangular: the view sends updates to the controller, the controller updates the model, and the view gets updated directly from the model."

[Source: Multi-Tier Architechture ]

2. Classes and Library: Units of Code

It helps to think of codes in units when deciding how to organize them. For small applications, a class is a good enough 'small' unit. When applications are larger, a library might be more appropriate. Simply put, a library is just a collection of classes that are grouped together based on their functionality (or on the developers whims and fancy :).

For example, you might have bunch of classes that handle different input validations, and you could lump it all together into a single file and call it the 'Input Validation Library'.

Classes and libraries make it easier to re-use code, and make the coding more modular thus making it easier to manage.

When planning your application, decide on what classes will be in the Model, View and Controller. If your application is large you can then also organize your classes into libraries within each component, if necessary.

Note: I haven't touched PHP for a loooooong time nor used codeigniter. Whatever I've said here broadly applies to MVC application development with any OOP language.

models are for database work. use libraries for the core functionality of the web app. use helpers for formating etc that might not be app specifc and can be called statically. libraries are instanced while helpers are not.