Where to put db join queries?

I usually follow the examples in the docs and videos. https://laravel.com/docs/5.6/queries

If eloquent, then main queries in models, called from controller, which is MVC.

If new actually work some of Taylor's examples from the docs, plus ver 5.2 had a free tutorial, code is on github https://laravel.com/docs/5.2/quickstart-intermediate

1. I dont know your actual logic, but , ... isnt model relations enough to solve your join problem ?

2. are you going to use queries with those joins more than once ? put it in the model ... not ... wherever.

3. MVC is an "approach" to organice your code, ... but ... use it the way you want ... and if you want to "break" the convention ... do it knowing what you are doing.

Is like DB Tables normalization ... sometimes ... because of query speed ... you need not to follow strict tables normalizations ... so .... I think you get my point.

@jlrdw I was hoping you'd chime in. Your explanations in some other threads were very helpful to me. I'm not a total beginner and I've followed a good number of tutorials successfully. But since they're tutorials, things are typically simplified, and everything is very neat and tidy. I get stuck when I go to actually make something even moderately complex. I can make it work just fine but it's a jumbled mess all jammed in the controller.

I just want to hear more experienced developers like you guys talk more about how you structure your projects for real applications. I've noticed a lot of people talking about repository design pattern but that seems like overkill for what I'm trying to do.

I'm trying to compare inventory levels between multiple ecommerce platforms. I have a model for each. Where would code go to fetch data from each table, compare them, and return results?

Some people use the repository pattern using interfaces, where you have the queries in a separate class.

Here's an older video lesson about it: https://laracasts.com/lessons/repositories-and-inheritance

Actually if using query builder only, the db facade becomes the model, and I usually just write the query in controller. Something like:

        $query = Dog::where('dogname', 'like', $dogsch);
        if ($aval == "n") {
            $query->where('adopted', '=', 1);
        } else if ($aval == "y") {
            $query->where('adopted', '=', 0);
        }
        $dogs = $query->orderBy('lastedit', 'DESC')->paginate(5);

There have been talks on larger controller vs repository. If re-usable then repository is fine, if a unique query just for that view, then controller.

But either will give same results.

One advantage to repositories is that sometimes you're running the same queries in multiple controllers. If you change something then you need to go back and update all of those queries. With a repository, you just update the single query in the repository.

Another benefit is you then have a single file that contains all of your queries for a model instead of littered throughout the app, keeping the data layer separate.

One more benefit is if you decide to one day change db engines or something. Again, you just need to update the repositories and the rest of the code using them will "just work".