PHPackages                             tamkeenlms/laravel-data-selector - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Database & ORM](/categories/database)
4. /
5. tamkeenlms/laravel-data-selector

ActiveLibrary[Database & ORM](/categories/database)

tamkeenlms/laravel-data-selector
================================

An extra layer on top of Laravel's Eloquent to help with selecting and retrieving data from the database.

v1.0(8y ago)013MITPHPPHP >=5.4

Since Jan 4Pushed 8y ago1 watchersCompare

[ Source](https://github.com/tamkeen-tms/laravel-data-selector)[ Packagist](https://packagist.org/packages/tamkeenlms/laravel-data-selector)[ RSS](/packages/tamkeenlms-laravel-data-selector/feed)WikiDiscussions master Synced yesterday

READMEChangelog (1)Dependencies (1)Versions (2)Used By (0)

About
=====

[](#about)

This is a fairly simple extra layer that works on top of Laravel's amazing Eloquent. Its objective is to help you make data selection/retrieval from the database more clean and standard across your codebase.

Why and how it works
--------------------

[](#why-and-how-it-works)

Well, with Laravel we usually use the models we created to select data (like in `Client::all()`), Eloquent of course makes customizing this simple query very straight formward by offering methods like `where(...)`, `limit(...)` .. etc. This of course is great, but the problems happens when you find yourself repeating much of this *Where, OrderBy, Limit, ...etc* everywhere. These methods simply represents much of the logic behind the whole application, because you use them to control the final output that will be shown to the user. And because we always find ourselves changing these conditions all the time in different places we always wind up with different queries that are supposed to be doing the same thing!

Of course you can use scopes to solve this problem, and it's sufficent, but I am trying to suggest a different approach, one that you can consider abit cleaner and much more elegant, away of polluting your models. You will simply create an API for each Model, a "Selector" that you can call anywhere and ask for a specific query. Lets take an example; you have a *Client* model, which represents your "clients" database table:

```
class Client extends Model{
    public $table = 'clients';
    protected $guarded = [];

    public function orders(){
        return $this->hasMany(Order::class);
    }
}
```

Later you will find yourself adding more and more scopes like these:

```
public function scopeActiveOnly($query){
    return $query->where('active', true);
}

public function scopeRegisteredThisMonth($query){
    return $query->whereMonth('created_at', \Carbon::now());
}
```

With this library you will get to separate these scopes from the model into a cleaner interface, where you can focus better on them, group them into meaningful api-like calls and serve your application logic better!

How to use it
=============

[](#how-to-use-it)

Installation
------------

[](#installation)

Simply pull it into your project via composer:

```
composer require tamkeenlms/laravel-data-selector

```

Now, for each model you have you will create a Selector class, one that will extend *DataSelector\\Selector*, and then you will get to call this selector and ask it for x or y. I suggest you create a new directory for your selectors under */app*.

```