1

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
    Your question is impossible to answer correctly, since it will be based on opinions. Looking at your description of the problem, the actual problem seems to me that you do not understand what the MVC-pattern is and why it is used in so many applications and frameworks. Try to work this out and reflect that additional knowledge on your current project. – Allmighty Mar 11 '15 at 11:01
  • @Adimeus I get that the first point of the list is pretty subjective but that's really not the main question. I'll edit the first point since no one on stackexchange likes the word should – Loko Mar 11 '15 at 11:03
  • I believe Adimeus hit the nail on the head in his answer – Bill Garrison Mar 17 '15 at 15:54
7

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:

    1. All your controller methods will become larger and larger as books get more and more complex
    2. 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.
    3. 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
    4. Etc.
    5. 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.

| improve this answer | |
  • I only wish i could +1 this more than once at the cost of reputation :). Seeing fat controllers with no SoC makes my head hurt. – Bill Garrison Mar 17 '15 at 15:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.