Models versus Autoloading Files

[unemployment]

I'm in the process of trying to create my own framework and I was curious if someone could tell me what the purpose of a model is over using library files defined by subject.  Doesn't it make more sense to set them up on a per subject basis rather than a file name basis?

[PeoMachine]

What did you mean? I can't understand your point. Can you give us some example?

[unemployment]

I used to set up my "Models" as seperate library files that would then just be pulled into a page.  I labeled each file based on subject so for example, one file might be named "news_feed.class.php". My understanding would be that in MVC I would just place the contents of that file in my home_model.php file.  So instead of organizing the models contents by subject, I would be adding it specifically to a file name where the content was needed.  To me, this makes the structure of the content more difficult to understand.

[Jessica]

You're still not making any sense.

 

Using MVC, every model should be it's own file, not all in one model file. Some models might extend other models but still be their own file. Every class whether a model or a controller, needs to be it's own file.

 

And that has little to do with autoloading. You can easily autoload the files. In fact you should.

[unemployment]

You're still not making any sense.

 

Using MVC, every model should be it's own file, not all in one model file. Some models might extend other models but still be their own file. Every class whether a model or a controller, needs to be it's own file.

 

And that has little to do with autoloading. You can easily autoload the files. In fact you should.

 

True... this has almost nothing to do with autoloading...

 

What I am trying to say is that if I were making a news feed for my index I would typically put all the news feed functions in a model with the respective file name.  Files names being: index_model.php, index_controller.php and index_view.php.  My question is, why do frameworks do this?  We would your models have the respective file name and not just be organized by subject.  So instead of index_model.php I would have news_feed.php.  Does that make sense?  Do you have to follow the name convention?

[KevinM1]

You don't have to follow that naming convention.  The term 'convention over configuration' is used a lot, which means that 3rd party frameworks will automatically know how to wire up and integrate various classes and other content files if they adhere to the standard convention.  You can bypass that convention and create your own, but that generally requires tinkering with the plumbing underneath.  The convention itself is largely similar between frameworks because:

 

1. It works.

2. It allows someone familiar with one framework to be familiar with another.

 

That's why it's a convention.

 

That said, if you're home-rolling your own framework, you can decide how you want to do it.  You'll just have an unconventional project.

[PeoMachine]

I dont know if i understood... you dont know how to name and organize your classes. I'm right?

 

If yes, read this https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md. This is a convention for naming the files and autoloading classes. You should look the structure of other frameworks like Zend and Symfony too, maybe you will understand.

[unemployment]

You don't have to follow that naming convention.  The term 'convention over configuration' is used a lot, which means that 3rd party frameworks will automatically know how to wire up and integrate various classes and other content files if they adhere to the standard convention.  You can bypass that convention and create your own, but that generally requires tinkering with the plumbing underneath.  The convention itself is largely similar between frameworks because:

 

1. It works.

2. It allows someone familiar with one framework to be familiar with another.

 

That's why it's a convention.

 

That said, if you're home-rolling your own framework, you can decide how you want to do it.  You'll just have an unconventional project.

 

Well said... It just doesn't make sense to me why that convention exists.  If I have model named index_model.php then I have no idea what that model is actually doing by looking at it's name.  What if you had global models?  How do you account for using DRY programming?  Lets say I have and index_view.php and a contact_view.php and they both needed the same functions.  Would I just create a library file to pull in those model extensions?

[Adam]

To ensure everyone's on the same page here, what's your definition of a model?

[unemployment]

To ensure everyone's on the same page here, what's your definition of a model?

 

My definition of a model is a class / function that handles data. 

[Jessica]

Why would it be named index_model? Name it what it handles. Things like UserModel, NewsModel, CommentModel, etc.

[unemployment]

Why would it be named index_model? Name it what it handles. Things like UserModel, NewsModel, CommentModel, etc.

 

Ok, that's what I thought, but don't a lot of frameworks name it respective to the page being loaded?  Maybe I am wrong about that.  I hope I am.

[KevinM1]

To ensure everyone's on the same page here, what's your definition of a model?

 

My definition of a model is a class / function that handles data. 

 

A model should represent data.  Like a user.  Or a blog post.  Or a store item. 

 

---

 

I hesitate to write this as it may confuse you.  There's actually two kinds of models:

 

Your honest-to-goodness models which represent your site's business entities.  They interact with one another behind the scenes.

 

View/edit models, which are simple DTOs that are used as a proxy to the data that's in the 'real' models in order to narrow down the model data into manageable bits in order to render their data to the screen, or to allow users to edit what's in there.

 

Now, separate view/edit models are not a requirement.  They're not considered part of the MVC pattern, really, but they are used.  A lot of times, you won't need them.  If your 'real' models are simple, there's nothing wrong with using them directly.  View/edit models are just a way to keep the I/O of models loosely coupled to the 'real' models and streamlined.

 

---

 

And jesi is right - the MVC convention is that controller actions and their views should be related by name, but models can have any name they want/need.  I should have mentioned that earlier.  So, UserModel, BlogPostModel, StoreItemModel all make sense.

[Jessica]

Usually the page would be something like /user/edit

Which would load the UserController and call the edit() method, load the  UserModel, and the view template would be edit.

 

An index page would be site.com/user/ which would likely mean the logged in user, and you'd have logic which would say if there is no "action" or method specified, use a main() or index() type function.

 

You'd also need to decide if you're going to do

site.com/user/view/12345  (controller/action/parameter)

OR

site.com/12345

 

And add in special handling if the second.

[unemployment]

Great to hear.  I plan on naming them based on what they do, rather than what filename they associate with.  Thanks.