Where to place the queries?

Normally I'd say a lot of people follow the following practice:

If your project is rather "large" you would probably use repositories. If that extra layer is a PITA or the project is rather small, then just put everything into models. (I like to create a separate folder for models rather than just them lay all over the place.)

My typical setup: I use my controllers to "control" my models for managing "model stuff" (ie, whatever extends a model like: presenters, translators, and such) and repositories for the actual queries ( I skip the repository interface since that is the layer I find to be a PITA).

Thanks for your explanation, can I get you to post an example? Preferably with use of repositories. If I understand you well, you have your methods in your models to do the work, and you work with them in the controller? I'm not quite sure what a repository means, in this context, maybe you can provide me with a link or such?

I found this link about architecture, maybe that's what you're trying to say? http://laravel.io/forum/06-17-2014-controller-service-repository-architecture However I'm struggling understanding and implementing it.

@Kudos You should never have queries in your controller. Queries belong in models, and even then they should be built up with the query builder as opposed to raw SQL statements.

@Kudos here is a goot exaple of using a repositories pattern https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5/

@martinbean the controller is where queries go.
Example directly from the documentation:

<?php

namespace App\Http\Controllers;

use DB;
use App\Http\Controllers\Controller;

class UserController extends Controller
{
    /**
     * Show a list of all of the application's users.
     *
     * @return Response
     */
    public function index()
    {
        $users = DB::table('users')->get();  //THIS IS A QUERY

        return view('user.index', ['users' => $users]);
    }
}

@jlrdw Not everything in documentation is a best practice(this is mainly for a simplicity of demonstration). In a case of small web application with only one maintainer it is ok to put queries in controller. But if you work as a team or your project is bigger than usual, you need more abstraction. That is what repositories are for.

@jlrdw The documentation is for example only. There are plenty of things in the documentation that are for demonstrative purposes only and not actually intended to be used in production code. Queries in a controller method is one of those things.

@andy lol interfaces are generally overkill

@jlrdw Laracast is also a demonstration( of some features or techniques or technologies), and many times it is being said in video that is just a demonstration and it should be understood literally. Take a look at what MVC and also do not take demonstration videos literally.

anyway we are actually trying to help him, and you are bringing unnecessary confusion and offtopic to this thread

@Kudos take a look at that article I posted earlier, there is also a brief explanation of what repository is and what is it for.

A model

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class Photo extends Model
{
    /**
     * Get all of the owning imageable models.
     */
    public function imageable()
    {
        return $this->morphTo();
    }
}

class Staff extends Model
{
    /**
     * Get all of the staff member's photos.
     */
    public function photos()
    {
        return $this->morphMany('App\Photo', 'imageable');
    }
}

class Product extends Model
{
    /**
     * Get all of the product's photos.
     */
    public function photos()
    {
        return $this->morphMany('App\Photo', 'imageable');
    }
}

Retrieving Polymorphic Relations

Once your database table and models are defined, you may access the relationships via your models. For example, to access all of the photos for a staff member, we can simply use the photos dynamic property:

This would go in the controller

$staff = App\Staff::find(1);  //THIS IS THE QUERY GETTING RESULTS FROM MODEL  
                                            // THIS DOES NOT AND SHOULD NEVER BE IN THE MODEL

This would go in the view

foreach ($staff->photos as $photo) {
    //the loop here
}

PERIOD
If you don't understand this, I sincerely hope you aren't writing real world production sites.

@jlrdw So even though a view uses multiple queries to get data to pass to the view, every single query should be in the respective function in the controller? If I need to find something complex, let's say I have to find a userID first, then use the userID to locale some data in another table, and then use the data located in there to find something else in another table.

That is a query ? Is it really ? It is calling a Repository that instantiate a model and perform calls on that model.

To put things straight. I am not saying it is bad calling model(with scopes) from a controller, it is OK and in most cases using repositories is unnecessary overkill, but building a query with querybuilder in a controller is not a good idea for many reasons, such as maintenance or breaking MVC pattern.

so @jlrdw please posting here a code with bad commentary, when you do not know what is it about

@Kudos

I picked up a lot from this: https://github.com/mrakodol/Laravel-5-Bootstrap-3-Starter-Site

I don't think it has repositories but they are basically just like calling a model: $this->model versus $this->model_repository You will need to call your model within the repository.

I also learned a lot from this: https://github.com/sdebacker/TypiCMS

It has interfaces and scopes and all kinds of goodies to learn about but at the same time more advanced in some ways.

@ documentation and laracast examples.

lol, at least the docs don't put all the example code into the routes file ;)

After watching a lot of Jeffery's videocasts, it "seems" (I could be wrong) he has gone from being very strict about moving things into the proper places to being more pragmatic and suggesting to still follow proper usage but with the idea that sometimes breaking a "rule" makes more sense.

So, why not just make sure that your code is easy to follow, clean as possible, DRY as possible, and have comments that add to understanding rather than just explain what your code already does!

Besides, who knows what flavor of the week design patter is going to make this week's obsolete and old school ;)

https://laracasts.com/discuss/channels/laravel/where-to-place-the-queries/replies/107044

This. That's 100% true. You don't put your queries in your models. Queries are returning models.

The only thing you could add is a repository layer. You would add the query

App\Staff::find(1);

to the repository and call something like $this->staffRepository->get(1) in the controller. But a repository is by no means the only way to go. I actually don't like them that much. Not even in bigger projects. That's because I feel like I'm repeating a lot of eloquent stuff in the repositories. But at the end of the day, this all depends on project scope, size and personal/team-preference.

...so after sitting here and reading all of this, it sounds like the quickest, simplest, cleanest thing to do when you need to create a complex custom query with the query builder is to create a private method in your controller class, pass it some parameters, run the query, and return the output to the controller method that's responding to the request...

Yes, I understand this isn't a pattern you would want to utilize for a large scale production application, but for something that just needs to output a couple of custom reports...I'm not seeing the need to adopt an entire repository pattern just to do so.

Please correct me if I am mistaken.

Today someone told me don't write queries to controller instead of this write in model. So got this whole conversation, but did not get any strong reason not to write queries in controller. So, looking for some more thoughts.

The answer is - it depends.

if you have simple queries, you can write them in the controller. Really your controller should be executing Model methods and then passing data the view. If you have complex functionality, its clearer to pass this into Models and then you can write accompanying unit tests to ensure these methods stay working.

This being a very old post, I switched to query scopes. A simple find one record I still put in controller, but for a larger query I make a scope:

    public function scopegetPets($query, $petsearch = '')
    {
        $petsearch = $petsearch . "%";
        $query->where('petname', 'like', $petsearch);
        if (ChkAuth::chkRole('admin') === false) { // custom rbac
            $userid = Auth::user()->id;
            $query->where('ownerid', '=', $userid);
        }
        $results = $query->orderBy('petname', 'asc')->paginate(5);
        return $results;
    }

Called from controller like:

$pets = Pet::getPets($petsearch);

Preference has a lot to do with it, but scopes is one way to go.

preferably with scope names that reflect what they do.

Also preferably query scopes that do just one thing. It's not normal to put the entire query into a query scope. And more importantly, it's definitely not normal to finish the query with paginate or get or first in a query scope.

@tray2 @ramniksingh Yes, someone else likes the KISS rule. I was a contributor to another framework and the moto was KISS. The old Simple php mvc framework. Been some time now.

But like @tray2 suggested, those videos are good, also code is free on Github to study.

Good luck in your learning.