I think i've had a misconception about models

[eluser]drewbee[/eluser]
I was reading through this link http://blog.astrumfutura.com/archives/37...iated.html and found it rather interesting.

Not only are my models currently singletons to the specific controller, they do not do much more then grab and set data in the database.

Is this the same path everyone else has been taking? I just realized none of my models are reusable in the fact that they are specific to each controller.

How is everyone else following through with this?

Currently I have a login, logout, registration etc model. What I am now currently thinking is that I should just rather have a *users* model, to which can do login, logout, registration, and any manipulation to the user accounts table, as of course retrieving information. I guess this would actually be split into a auth model, and a users model, but for point of purpose let's just go with this.

I really like how the article stated that controllers are suppose to be tightly bound to the underlying framework, while models are not. Simply initiated and used.

This other method would create a slight bit more overhead, in the sense that if I needed to load a full blown model for one simple update, but for me, this is an acceptable hit in the sense that I maintain more code re-usability avoiding a new model file for every controller.

Thoughts on this?

[eluser]Eric Barnes[/eluser]
My personal method is to use one model for one set of things. For example:
articles_model
categories_model
users_model
init_model
db_model

Then each one has methods that are only used for things related. So in articles it would be insert, update, delete, search, etc..

Of course the beauty of this framework is you can set it up however you want and what makes sense to you.

[eluser]drewbee[/eluser]
Agreed, and this is exactly what I am thinking I am going to be changing my methodology too. It just seems silly to be creating a new model for every controller, and I really think I got the wrong concept down on this.

[eluser]jalalski[/eluser]
Think of Models as representing the Nouns of the system.
And Controllers of representing the Verbs.

For instance, a blogging system will have 'Posts', 'Comments', 'Users' and so on. A shopping cart system would have 'Products', 'Orders', 'Payments', 'Customers' etc. As a starting point these would define Models in the system.

A Controller would handle the Verbs or actions, and these are usually based around URLs that the user interacts with. So a URL might be index.php/cart/add/12 (add product id 12 to the users cart) and this will call on the facilities provided by a number of Models.

I happen to disagree with some of Brady's ideas there, but then he has his way of approaching a program and I have mine, so I won't say that he is wrong, but I will note that there is more than one way of doing a thing. He prefers to make Models 'fat' but I find that this pushes too much of the application logic down into the Models and, eventually, makes it hard to maintain (changes in one model can effect others, there is a lack of encapsulation) whereas I keep the application logic in the controllers and the data logic in the models.

I've also taken to splitting my Models into two. For instance, the Customers model will contain the Customers class which inherits from Model, but it will also contain a Customer class. So the Customers object is a container for Customer objects, which are what actually get passed around the system.

There are many ways of working with an MVC system... I tend to start from an OOP point of view and stress encapsulation and decoupling the Models as much as possible.

[eluser]jedd[/eluser]
Drewbee - this was the point I was approaching recently in [url="http://ellislab.com/forums/viewthread/111081/"]this thread[/url] with you.

Having a 1:1 relationship between controllers and models suggests, at least in that discussion, a relationship between controllers and the database, and that didn't sit well.

My models describe things -- same way that earlier posters on this thread have suggested.

For example, my Member model handles several tables - users, avatars, permissions (two tables), locations (two tables).

My Taxonomy model handles about 25 tables.

They provide functionality to whatever controller needs them. Member is referenced mostly by about three controllers, as well as the MY_Controller. Taxonomy will be referenced by about 5 controllers I expect. My message model will be utilised by just two controllers.

One thing that is potentially difficult is working out what upper limit, if any, should be put on a given Model file. There was a discussion recently that suggested several hundred lines was such a limit, but I'm far more relaxed about overly large files. I reckon the file system can deal with that problem, and splitting my logic up based on arbitrary file sizes seems a bit misguided.

[eluser]drewbee[/eluser]
Yup. I'm not sure why I started down this path -- but I am glad it is something I can correct now.

I wondered why it seemed so silly in the way I was doing it... but never questioned because I thought I had the right methodology.

As for file size, well, it can't really be that big of a deal. Albeit the fact that I am working on Cold Fusion, a custom framework has been developed and a lot of the components have an absolute huge amount of lines to them. (Usually around a few thousand a piece);

I don't really notice to much performance hit's on this side, and would expect the same out of PHP; especially given the fact PHP is faster / less memory intensive.

[eluser]drewbee[/eluser]
Well,

I have gone through and re-wrote my entire 'base' script. Things make so much more sense now. I appreciate everyone input on this one and glad that I caught my little mis understanding before I got too far into the game haha.