Selecting orders submitted by a user, segregated by status I have recently started using Laravel as my chosen framework. It is my first time using a framework. As I have made progress through my project, my controller methods have started to increase in size. 

My concern is, I feel like I am doing it wrong. It seems way off of the OO approach. 

An example of one of my controller methods: 

public function viewUser($name)
    {
        $orders = Orders::where('submitter', $name)
            -&gt;where('closed', false)
            -&gt;where('ceased', false)
            -&gt;where('cancelled', false)
            -&gt;orderBy('updated_at', 'desc')
            -&gt;get();

        $completeOrders = Orders::where('submitter', $name)
            -&gt;where('closed', true)
            -&gt;where('ceased', false)
            -&gt;where('cancelled', false)
            -&gt;orderBy('updated_at', 'desc')
            -&gt;get();

        $cancelledOrders = Orders::where('submitter', $name)
            -&gt;where('closed', false)
            -&gt;where('ceased', false)
            -&gt;where('cancelled', true)
            -&gt;orderBy('updated_at', 'desc')
            -&gt;get();

        $ceasedOrders = Orders::where('submitter', $name)
            -&gt;where('closed', false)
            -&gt;where('ceased', true)
            -&gt;where('cancelled', false)
            -&gt;orderBy('updated_at', 'desc')
            -&gt;get();

        return view('admin.order-overview')-&gt;with('orders', $orders)
            -&gt;with('completeOrders', $completeOrders)
            -&gt;with('cancelledOrders', $cancelledOrders)
            -&gt;with('ceasedOrders', $ceasedOrders);
    }


As you can see I run 4 seperate queries to get my desired results then I pass them to my view. 

Is there a neater, more professional way to approach the above example?
I see two opportunities to improve your code.

1. Custom orders collection 

This would be the fast and easy approach. Make a custom 'Orders' collection that extends the Eloquent collection. On that collection, you can add your custom filters for 'completed', 'cancelled' and 'ceased'. By overwriting the newCollection method on the Order model, you can make it automatically return this custom Orders collection when queried. You can then assign that collection to your view, and there you can ask the collection for the different types of orders and use them as you please. Or you could do that in your controller as well if you prefer.

2. status_id in stead of flags 

You may take it a step further, depending on how far you want to refactor your data and the scope of your app. In stead of working with those 3 booleans for determining the 'type' of order, consider working with a single 'status_id' column. You could for instance define in your model:

const STATUS_COMPLETED = 1;
const STATUS_CEASED = 2;
const STATUS_CANCELLED = 3;

Then you can just fetch all your orders (possibly paged, or with some filters added) in a single query, and again filter on your collection to get the order type you need. And if anywhere in your app you only need orders with a certain status, you can just do something like Orders::where('status_id', Orders::STATUS_CANCELLED)-&gt;get();

I can see a few aditional advantages for this approach:


It would be very easy to put an index on that status column, which could greatly improve query performance
Query performance will be better anyway, since you only need a single where condition, which is obviously better then 3
If you later decide to add an extra status, like 'shipped' or 'returned' or something, you would only have to add a few constants, your data would remain in tact.
It is just semantically more correct imo. An order can not be confirmed and cancelled at the same time, but what if you make a mistake somewhere. You the risk creating corrupt data.
This approach would make it fairly easy to expand your application with a full order history, by creating 'status_changes' table ('order_id', 'status_id', 'date' , ...), to which you would write the status each time you change it.


As I said, how far you should go depends on the scope of your project (and your budget), as always. But it wouldn't be that big a job I think, and the benefits would be substantial. 

Let me know if you want me to elaborate on anything, or if you want me to add some (pseudo) code. Hope it helps!