I started working with Laravel about a month ago and I started by reading the documentation etc. Now I’m working on a project in Laravel 4.2 and I skipped some parts of the full documentation. In my current project I’m not using models and my fellow programmers tell me it’s good to use models. I know it’s pretty standard to just use models in a Laravel project and I’ve read parts of the documentation of models by now. I see it’s a clear way of working with tables etc. Now that I’m like in the middle of my project, I dont know if switching to models now, would be a big advantage. Since I have no experience with models. (So I have to learn it from the start). I’m currently doing everything in the Controllers. I cant see the disadvantage in using the query builder from Laravel in my controller instead of using the models. I do plan to eventually start other projects with models, but switching to models right now doesn’t seem like the best thing to do in the middle of my project.
This is a real project. I’m planning to get it online and people will actually use it.
Im still a student
So basically:
- Is there a reason for me to switch to models in my current project?
- Is there a difference in performance between my method and models?
3
The real question you would have to ask is, “Why should I use an MVC pattern”.
The reasons for using such a pattern can only be explained when one has an understanding of principles that programmers want to adhere to for a number of reasons, but maybe the most important one:
Seperation of concerns
The value of separation of concerns is simplifying development and maintenance of computer programs. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently. Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections.
Source: Wikipedia
As described at the link I’ve posted, not implementing ‘some’ seperation of concern can, or will, lead to code being unreadable, unmanageable or worse – plain broken (examples? look for spaghetti-code or big-ball-of-mud)
Simple Example:
- You’ve got a website in which books can be bought.
-
There are 26 different pages (controller methods) in which books are displayed, or in any way used (eg. Admins must add – edit – delete books, users must add-edit-delete comments on books, etc)
-
If you were to implement all your “book-logic” into each controller method then:
- All your controller methods will become larger and larger as books get more and more complex
- After a few weeks you want to change something about the way your books are displayed, you have to change all 26 different controller methods using them.
- After a while, you will have no idea where to find that line of code that makes sure that if a book is not for sale for a small period of time, it won’t be displayed by all your controllers that have anything to do with selling books
- Etc.
- After hacking in tons of small changes in all your controllers, you get the flue, or go on a long and (well-deserved) holiday just before a major bug – and some other programmer has to quickly find and resolve it without your help. Credits to him if he solved it in a timely fashion.
Note: this is just a stupid, quickly made up example with certainly enough flaws, but it is about the general picture.
Now, let’s think about our project when we’ve set all our book logic into 1 model that is reusable throughout all our pages. Simplified this means you’ll have to implement a change once, and that fact should answer your first question.
1