I have the following lines of code that are being repeated, not only in many methods of a Controller but also in more than one Controller.
$Categories = \Cache::rememberForever('Categories', function() {
return \App\Models\Skill\Category_Model::all();
});
Is there any useful way that I can use this, such that the repeated code can be removed?
Use a Repository to access the Category_Model model:
//REPOSITORY CLASS
class CategoryRepository
{
public function getAll()
{
return \Cache::rememberForever('Categories', function() {
return \App\Models\Skill\Category_Model::all();
});
}
}
In the controllers where you need to get the categories, inject the repository from the controller's constructor, and access the repository from the methods:
//INJECT THE REPOSITORY IN YOU CONTROLLER'S CONSTRUCTOR
public function __construct( CategoryRepository $catRepo )
{
$this->catRepo = $catRepo;
}
public function index()
{
//get the categories from the repository
$categories = $this->catRepo->getAll();
}
This will keep your code DRY, as you only need to call $this->catRepo->getAll(); to get all the categories
Related
Let's suppose we have a site that shows a random list of 20 movies. Logged in users, however, can select their favorite movies, so those movies will be shown instead. This list of movies is shown both in the home page and in some other pages.
To follow the DRY principle, we could encapsulate this logic in its own class, and then inject this class wherever it is necessary to show the list of movies. This class will also have other methods that will be used throughout the application. For example, there is also a method to get one random movie.
The class could look like this (please note this is a simplified example):
class MovieService
{
/** #var Collection $movies */
protected $movies;
public function __construct()
{
$this->movies = Auth::check() ? Auth::user()->favoriteMovies : $this->randomMovies();
}
public function getRandomMovies(): Collection
{
return $this->movies->random(20);
}
public function getOneRandom(): Movie {
return $this->movies->random();
}
protected function randomMovies() {
return Movie::inRandomOrder()->take(20)->get();
}
}
Note: Please note that this is an example and that some things could be improved.
As this class could be used multiple times in the same request, it is a good idea to make it a singleton in the IoC container, so that the queries that are run when instantiated are not run more than once.
However, now we encounter a problem. We need this class in a private method in a controller. We could directly call the app container like app() or App::make() but we would like to avoid facades and global helpers with custom dependencies.
class HomeController extends Controller
{
/** #var MovieService $movieService */
protected $movieService;
public function __construct(MovieService $movieService)
{
$this->movieService = $movieService;
}
public function index()
{
$movies = $this->getMovies();
return view('home', compact('movies'));
}
protected function getMovies()
{
// Let's imagine there's some extra logic here so that we would actually need this method.
return $this->movieService->getRandomMovies();
}
}
We have found a problem. A controller's constructor is run before the middleware pipeline, which means that there's no session and, hence, no user identification. Now Auth::check() in MovieService is always returning false, so the default movies will always be shown.
What would you do to fix this?
It's cleaner to not use the constructor of an object for logic, only for managing dependencies. Coincidentally this will also fix the issue you're having by moving the Auth::check() logic to your getter methods instead. Besides that you could also consider injecting the AuthManager instead of relying on the Auth facade, but that's just a sidenote.
class MovieService
{
/** #var AuthManager $auth */
protected $auth;
protected $movies;
public function __construct(Illuminate\Auth\AuthManager $auth)
{
$this->auth = $auth;
}
public function getRandomMovies(): Collection
{
return $this->getMoviesForCurrentUser()->random(20);
}
public function getOneRandom(): Movie {
return $this->getMoviesForCurrentUser()->random();
}
protected function randomMovies() {
if ($this->movies === null) {
$this->movies = Movie::inRandomOrder()->take(20)->get();
}
return $this->movies;
}
protected function getMoviesForCurrentUser() {
if ($this->auth->check()) {
return $this->auth->user->favoriteMovies;
}
return $this->randomMovies();
}
}
In my application i have 4 models that relate to each other.
Forms->categories->fields->triggers
What I am trying to do is get the Triggers that refer to the current Form.
Upon researching i found nested eager loading, which would require my code to look like this
Form::with('categories.fields.triggers')->get();
Looking through the response of this i can clearly see the relations all the way down to my desired triggers.
Now the part I'm struggling with is only getting the triggers, without looping through each model.
The code i know works:
$form = Form::findOrFail($id);
$categories = $form->categories;
foreach ($categories as $category) {
$fields = $category->fields;
foreach ($fields as $field) {
$triggers[] = $field->triggers;
}
}
I know this works, but can it be simplified? Is it possible to write:
$form = Form::with('categories.fields.triggers')->get()
$triggers = $form->categories->fields->triggers;
To get the triggers related? Doing this as of right now results in:
Undefined property: Illuminate\Database\Eloquent\Collection::$categories
Since it is trying to run the $form->categories on a collection.
How would i go about doing this? Do i need to use the HasManyThrough relation on my models?
My models
class Form extends Model
{
public function categories()
{
return $this->hasMany('App\Category');
}
}
class Category extends Model
{
public function form()
{
return $this->belongsTo('App\Form');
}
public function fields()
{
return $this->hasMany('App\Field');
}
}
class Field extends Model
{
public function category()
{
return $this->belongsTo('App\Category');
}
public function triggers()
{
return $this->belongsToMany('App\Trigger');
}
}
class Trigger extends Model
{
public function fields()
{
return $this->belongsToMany('App\Field');
}
}
The triggers run through a pivot table, but should be reachable with the same method?
I created a HasManyThrough relationship with unlimited levels and support for BelongsToMany:
Repository on GitHub
After the installation, you can use it like this:
class Form extends Model {
use \Staudenmeir\EloquentHasManyDeep\HasRelationships;
public function triggers() {
return $this->hasManyDeep(Trigger::class, [Category::class, Field::class, 'field_trigger']);
}
}
Form::with('triggers')->get();
Form::findOrFail($id)->triggers;
So, lets say I do have a simple Controller that handles Books.
App\Http\Controllers\SimpleBooksController
Inside routes.php I register a route for it:
Route::get('books/{id}','SimpleBooksController#doSimpleStuff');
But the world of books is not so simple. So I would like to have another Controller that handles the really complex book stuff.
In my head I imagine that something like this would be really useful:
class ComplexBooksController extends SimpleBooksController
So that routes that are not explicitly handled by the child class fall back to the parent class.
Now let's say each book knows if it is complex or not: $book->isComplex
And what I would like to do would be something like this
if (!$book->isComplex) {
// route 'books/{id}' to SimpleBooksController#doSimpleStuff
} else {
// route 'books/{id}' to ComplexBooksController#doComplexStuff
}
So, how could one accomplish this?
* edit *
The way I am currently handling this, is by setting the Controllers in routes.php statically, but let them listen to parameterized routes:
Route::get('books/simple/{id}', 'SimpleBooksController#doSimpleStuff');
Route::get('books/complex/{id}', 'ComplexBooksController#doComplexStuff');
According to the responses documentation, you should be able to use an anonymous function and return a redirect to the correct controller.
This assumes you have the data in a books table with isComplex:
Route::get('books/{id}', function($id) {
$result = DB::select('SELECT is_complex FROM books WHERE id = ?', [$id]);
if (empty($result)) abort(404);
$book = $result[0];
if ($book->is_complex)
return redirect()->action('SimpleBooksController#doSimpleStuff');
else
return redirect()->action('ComplexBooksController#doComplexStuff');
});
Your approaching this in the wrong way. You should not be trying to handle it with different controllers and routes.
A route for books should be the same - regardless of the book.
Your controller then makes a determination if the book is simple or complex - and calls the appropriate Command to handle this.
Route:
Route::get('books/{id}','BooksController#doSimpleStuff');
Controller:
class BooksController extends Controller
{
public function showBook($book)
{
if ($book->isComplex()) {
$this->dispatch(new HandleComplexBook($book));
} else {
$this->dispatch(new HandleSimpleBook($book));
}
}
}
Then you just have two commands - one for simple books, and one for complex books
class HandleComplexBook extends Command implements SelfHandling {
protected $book;
public function __construct(Book $book)
{
$this->book = $book;
}
public function handle()
{
// Handle the logic for a complex book here
}
}
class HandleSimpleBook extends Command implements SelfHandling {
protected $book;
public function __construct(Book $book)
{
$this->book = $book;
}
public function handle()
{
// Handle the logic for a simple book here
}
}
I am thinking a best solution at the same time a lazy solution to filter collection in eloquent result in Laravel. I want to filter all my $videos collection in all my controllers. Is that possible to do without rewriting the controllers and instead put it in the model?
Here is my filter code:
$videos = $videos->filter(function( $video ){
return $video->isPublished();
});
Use query scopes. You can learn from here. And in your case, it would be something like this:
class Video extends Eloquent {
public function scopePublished($query)
{
return $query->where('published', '1');
}
}
class VideosController extends BaseController {
public function showPublishedVideos()
{
return View::make('published_videos')
->with('videos', Video::published()->take(10)->get());
}
}
In Laravel 4, query scopes are available on all queries (including ones generated by relations queries). This means that for the following (example) models:
Customer.php:
<?php
class Customer extends Eloquent {
public function order() { return $this->hasMany('Order'); }
}
Order.php:
<?php
class Order extends Eloquent {
public function scopeDelivered($query) { return $query->where('delivered', '=', true); }
public function customer() { return $this->belongsTo('Customer'); }
}
Both of the following work:
var_dump(Order::delivered()->get()); // All delivered orders
var_dump(Customer::find(1)->orders()->delivered()->get()); // only orders by customer #1 that are delivered
This is useful from within a controller because the query logic for finding delivered orders doesn't have to be repeated.
Recently, though, I've been convinced that the Repository pattern is optimal for not only separation of concerns but also for the possibility of a ORM/DB switch or the necessity of adding middleware like a cache. Repositories feel very natural, because now instead of having scopes bloat my models, the associated queries are instead part of the Repository (which makes more sense because naturally this would be a method of the collection not the item).
For example,
<?php
class EloquentOrderRepository {
protected $order;
public function __construct(Order $order) { $this->order = $order; }
public function find($id) { /* ... */ }
/* etc... */
public function allDelievered() { return $this->order->where('delivered', '=', true)->get(); }
}
However, now I have the delivered scope repeated, so to avoid violating DRY, I remove it from the model (which seems logical as per the justification above). But now, I can no longer can use scopes on relations (like $customer->orders()->delivered()). The only workaround here I see is somehow instantiating the Repository with the pre-made query (similar to what is passed to the scopes in the models) in the Relation base class. But this involves changing (and overriding) a lot of code and default behavior and seems to make things more coupled than they should be.
Given this dilemma, is this is misuse of a repository? If not, is my solution the only way to regain the functionality that I would like? Or is having the scopes in the models not tight enough coupling to justify this extra code? If the scopes aren't tight coupling, then is there a way to use both the Repository pattern and scopes while still being DRY?
Note: I am aware of some similar questions on similar topics but none of them address the issue presented here with queries generated by relationships, which do not rely on the Repository.
I've managed to find a solution. It's rather hacky and I'm not sure whether I consider it acceptable (it uses a lot of things in ways that they likely weren't meant to be used). To summarize, the solution allows you to move scopes to the repository. Each repository (on instantiation) is booted once, and during this process all of the scope methods are extracted and added to each query created by the eloquent model (via macros) by way of a Illuminate\Database\Eloquent\ScopeInterface.
The (Hack-y) solution
Repository Pattern Implementation
app/lib/PhpMyCoder/Repository/Repository.php:
<?php namespace PhpMyCoder\Repository;
interface Repository {
public function all();
public function find($id);
}
app/lib/PhpMyCoder/Repository/Order/OrderRepository.php:
<?php namespace PhpMyCoder\Repository\Order;
interface OrderRepository extends PhpMyCoder\Repository\Repository {}
Adding Eloquent Repositories (and a hack)
app/lib/PhpMyCoder/Repository/Order/EloquentOrderRepository.php:
<?php namespace PhpMyCoder\Repository\Order;
use PhpMyCoder\Repository\EloquentBaseRepository;
class EloquentOrderRepository extends EloquentBaseRepository implements OrderRepository {
public function __construct(\Order $model) {
parent::__construct($model);
}
public function finished() {
return $this->model->finished()->get();
}
public function scopeFinished($query) {
return $query->where('finished', '=', true);
}
}
Notice how the repository contains the scope that would normally be stored in the Order model class. In the database (for this example), Order needs to have a boolean column finished. We'll cover the details of EloquentBaseRepository below.
app/lib/PhpMyCoder/Repository/EloquentBaseRepository.php:
<?php namespace PhpMyCoder\Repository;
use Illuminate\Database\Eloquent\Model;
abstract class EloquentBaseRepository implements Repository {
protected $model;
// Stores which repositories have already been booted
protected static $booted = array();
public function __construct(Model $model) {
$this->model = $model;
$this->bootIfNotBooted();
}
protected function bootIfNotBooted() {
// Boot once per repository class, because we only need to
// add the scopes to the model once
if(!isset(static::$booted[get_class($this)])) {
static::$booted[get_class($this)] = true;
$this->boot();
}
}
protected function boot() {
$modelScope = new ModelScope(); // covered below
$selfReflection = new \ReflectionObject($this);
foreach (get_class_methods($this) as $method) {
// Find all scope methods in the repository class
if (preg_match('/^scope(.+)$/', $method, $matches)) {
$scopeName = lcfirst($matches[1]);
// Get a closure for the scope method
$scopeMethod = $selfReflection->getMethod($method)->getClosure($this)->bindTo(null);
$modelScope->addScope($scopeName, $scopeMethod);
}
}
// Attach our special ModelScope to the Model class
call_user_func([get_class($this->model), 'addGlobalScope'], $modelScope);
}
public function __call($method, $arguments) {
// Handle calls to scopes on the repository similarly to
// how they are handled on Eloquent models
if(method_exists($this, 'scope' . ucfirst($method))) {
return call_user_func_array([$this->model, $method], $arguments)->get();
}
}
/* From PhpMyCoder\Repository\Order\OrderRepository (inherited from PhpMyCoder\Repository\Repository) */
public function all() {
return $this->model->all();
}
public function find($id) {
return $this->model->find($id);
}
}
Each time an instance of a repository class is instantiated for the first time, we boot the repository. This involves aggregating all "scope" methods on the repository into a ModelScope object and then applying that to the model. The ModelScope will apply our scopes to each query created by the model (as seen below).
app/lib/PhpMyCoder/Repository/ModelScope.php:
<?php namespace PhpMyCoder\Repository;
use Illuminate\Database\Eloquent\ScopeInterface;
use Illuminate\Database\Eloquent\Builder;
class ModelScope implements ScopeInterface {
protected $scopes = array(); // scopes we need to apply to each query
public function apply(Builder $builder) {
foreach($this->scopes as $name => $scope) {
// Add scope to the builder as a macro (hack-y)
// this mimics the behavior and return value of Builder::callScope()
$builder->macro($name, function() use($builder, $scope) {
$arguments = func_get_args();
array_unshift($arguments, $builder->getQuery());
return call_user_func_array($scope, $arguments) ?: $builder->getQuery();
});
}
}
public function remove(Builder $builder) {
// Removing is not really possible (no Builder::removeMacro),
// so we'll just overwrite the method with one that throws a
// BadMethodCallException
foreach($this->scopes as $name => $scope) {
$builder->macro($name, function() use($name) {
$className = get_class($this);
throw new \BadMethodCallException("Call to undefined method {$className}::{$name}()");
});
}
}
public function addScope($name, \Closure $scope) {
$this->scopes[$name] = $scope;
}
}
The ServiceProvider and Composer File
app/lib/PhpMyCoder/Repository/RepositoryServiceProvider.php:
<?php namespace PhpMyCoder\Repository;
use Illuminate\Support\ServiceProvider;
use PhpMyCoder\Repository\Order\EloquentOrderRepository;
class RepositoryServiceProvider extends ServiceProvider {
public function register() {
// Bind the repository interface to the eloquent repository class
$this->app->bind('PhpMyCoder\Repository\Order\OrderRepository', function() {
return new EloquentOrderRepository(new \Order);
});
}
}
Be sure to add this service provider to the providers array in the app.php config:
'PhpMyCoder\Repository\RepositoryServiceProvider',
And then add the app/lib to composer's autoload
"autoload": {
"psr-0": {
"PhpMyCoder\\": "app/lib"
},
/* etc... */
},
This will require a composer.phar dump-autoload.
The Models
app/models/Customer.php:
<?php
class Customer extends Eloquent {
public function orders() {
return $this->hasMany('Order');
}
}
Notice that for brevity, I've excluded writing a repository for Customer, but in a real application you should.
app/model/Order.php:
<?php
class Order extends Eloquent {
public function customer() {
return $this->belongsTo('Customer');
}
}
Notice how the scope is not longer stored in the Order model. This makes more structural sense, because the collection level (repository) should be responsible for scopes applying to all orders while Order should only be concerned with details specific to one order. For this demo to work, order must have an integer foreign key customer_id to customers.id and a boolean flag finished.
Usage in the Controller
app/controllers/OrderController.php:
<?php
// IoC will handle passing our controller the proper instance
use PhpMyCoder\Repository\Order\OrderRepository;
class OrderController extends BaseController {
protected $orderRepository;
public function __construct(OrderRepository $orderRepository) {
$this->orderRepository = $orderRepository;
}
public function test() {
$allOrders = $this->orderRepository->all();
// Our repository can handle scope calls similarly to how
// Eloquent models handle them
$finishedOrders = $this->orderRepository->finished();
// If we had made one, we would instead use a customer repository
// Notice though how the relation query also has order scopes
$finishedOrdersForCustomer = Customer::find(1)->orders()->finished();
}
}
Our repository not only contains the scopes for the child model, which is more SOLID. They also come with the ability to handle calls to the scope like a real Eloquent model would. And they add all scopes to each query created by the model so that you have access to them when retrieving related models.
Problems with this Approach
A lot of code for little functionality: arguably too much to accomplish the desired result
It's hacky: macros on Illuminate\Database\Eloquent\Builder and Illuminate\Database\Eloquent\ScopeInterface (in conjunction with Illuminate\Database\Eloquent\Model::addGlobalScope) are likely used in ways they weren't intended to be
It requires instantiation of the repository (MAJOR ISSUE): if you're within the CustomerController and you only have instantiated CustomerRepository, $this->customerRepository->find(1)->orders()->finished()->get() won't work as expected (the finished() macro/scope won't be added to each Order query unless you instantiate OrderRepository).
I'll investigate if there is a more elegant solution (which remedies the issues listed above), but this is the best solution I can find thus far.
Related Resources on the Repository Pattern
Creating flexible Controllers in Laravel 4 using Repositories
Eloquent tricks for better Repositories