MVC vs OOP in general?

[eluser]Joey Dendron[/eluser]
Hi there

I'm reading OOPHP books while working with CI. I've found myself writing lots of CRUDish models, but while CI's been wonderful for organising my code, I haven't been advancing very far in terms of my use of design patterns etc - IE my controller loads my invoice_model.php file, which tends to be pretty much where all my invoice code lives: I didn't sit down and UML an inheritance hierarchy of invoice types, or implement a Factory pattern for choosing between them at runtime. I'm a bit concerned that I'm falling into a trap of writing procedural code within the MVC framework.

Should I be learning to implement models with, EG, inheritance hierarchies or composition relationships - in which case, would that code belong largely in the model part of my application - or... is the MVC framework idea intended to circumvent me having to worry about that aspect of OOP?

I'd appreciate any thoughts, ideas, experience or advice..

Many thanks

Dave

[eluser]Dennis Rasmussen[/eluser]
When I began using CodeIgniter I tended to write all of my code in either a controller without using a model.
Then I sometimes ended up having DB functions in the view and what not.

Basically it takes practice to the beginner, and eventually you'll see how structured it becomes when you actually work out the MVC pattern.

Keep your CRUDs in your models. Basically one model for each table.
Keep your validation and loading in your controllers and keep the views completely free of functions, both CI and native PHP.

Oh and it's really not a bad idea to create an UML before any kind of project.

[eluser]Dennis Rasmussen[/eluser]
If you want to get a bit more advanced then read more about ORM for your models and some about Base Controllers.
Get a template engine to reduce the use of php code in your views (if that's your style).

Oh and maybe there's something you can use here:
http://www.2expertsdesign.com/tutorials/...pplication

[eluser]wiredesignz[/eluser]
I cannot stress how wrong it is to consider a model as a representation of a single database table.

A model is a representation of the real world. It can represent one or many tables, it may represent XML files, or any other external data source(s) that you might need.

http://www.phpwact.org/pattern/model_view_controller

Other design patterns are fairly advanced but can be used comfortably within CI.

There is no shame in writing simple applications to begin with.

[eluser]Dennis Rasmussen[/eluser]
[quote author="wiredesignz" date="1291299656"]I cannot stress how wrong it is to consider a model as a representation of a single database table.

A model is a representation of the real world. It can represent one or many tables, it may represent XML files, or any other external data source that you might need...[/quote]

My bad to meantion it like that, but what I meant was just a model for each source category and to the newbie, that's usually a database with several tables for each section of a simple project.

[eluser]WanWizard[/eluser]
[quote author="wiredesignz" date="1291299656"]I cannot stress how wrong it is to consider a model as a representation of a single database table.[/quote]
Exactly.

And if you use an ORM (where a model IS a representation of a single table), you'll have models calling models (which according to some is not done as it violates the MVC rules)...

[eluser]wiredesignz[/eluser]
ORM, Object Relational Mapping is NOT Models. How many times must I say this?

Models should encapsulate ORM. They are not ORM objects. ORM provides data access objects not models.

It is only the developers of DMZ and other libraries that decided to use the word "models" and force their DAOs onto the weak CI model class.

And you all get stuck with that concept.

[eluser]Phil Sturgeon[/eluser]
A Model can be an ORM object, that is how ORM works. There's no right snd wrong here wiredesignz, this is something we always disagree about. There is the "ideal" way, the easy way, the quick way, the clean way, etc. Read the design patterns on the Wiki but at the end if the day, the best way differs for everyone.

Models can represent a single table or multiple. They can represent XML, CSV, Monogo collections or whatever the hell sure, but the easiest way to use models in CodeIgniter is to have it representing a single table. Obviously not one model for each join table, as that would just be silly.

I personally prefer to use a model for each call as each model then just contains get/get_all/insert/delete/ etc for each table. Otherwise you end up with a LOT more code all built up in the same file which may not be used. It's the same idea as splitting down your controllers into very specific functionality, as any unused code is still loaded and parsed by PHP, but slows your app down for now reason. If I have methods that will always be used together it is quicker to put them in the same model, but if they are used separately then why have all the coded loaded each time?

Again, it's all down to whichever way is best for the developer and best for performance. Not black and white.

One thing to remember Joey is that MVC is not a restrictive form of OOP and they should not be considered different things. If you implement autoloading you can have models extending other models without any problems. The MVC triad in CodeIgniter is a little weak compared to other frameworks but this is only down to the PHP4 backwards compatibility which has been killed off now in CI 2.0. In the future I'm sure we can improve on this.

[eluser]wiredesignz[/eluser]
Sturgeon you are clueless man. Go learn something before writing so much garbage.

ORM is not models. If you are getting this info from using Ruby, I can tell you they have it wrong too.

The only reason we disagree is that you pretend to have a clue while misleading everyone.

Find me one piece of real technical literature that identifies models as ORM objects?

[eluser]Joey Dendron[/eluser]
This is really interesting stuff, thanks everyone for your posts. Wiredesignz/WanWizard, with that caveat about the meaning of the word "model" I'm going to have a good think about those ideas: ORM, a model encapsulating ORM, and models encapsulating other object structures that aren't themselves models (I guess?).

Another related question I came up with last night was: I'm guessing that there are instances where code in a model will instantiate an object from a class, but not using CI's $this->load functionality? EG if you're building an extended model that's an object composed of other objects? Is that valid?

Thanks again for your help, it's pretty inspiring to see new vistas on the horizon.

Dave