Correctly structuring Laravel project - php

Question

I have a view that shows a line of 10 numbers in a table (it's a dashboard of stats).
They are information on sales today, tomorrow, the day after etc, split by some different states.
Currently I have some code like:
class Transaction extends Eloquent {
// other methods that aren't relevant
public function scopeConfirmed($query)
{
return $query->where('status', '=', 'Confirmed');
}
public function scopeBooked($query)
{
return $query->where('status', '<>', 'Cancelled');
}
public function scopeDaysAhead($query, $days)
{
$start = \Carbon\Carbon::now()->addDays($days)->toDateString();
$end = \Carbon\Carbon::now()->addDays($days+1)->toDateString();
return $query->where('date', '>=', $start)->where('date', '<', $end);
}
// few other similar scopes
}
Then in my view I have:
(Simplified)
<td>
{{Transaction::->daysAhead(0)
->booked()
->count()}}
</td>
<td>
{{Transaction::->daysAhead(0)
->confirmed()
->count()}}
</td>
<td>
{{Transaction::->daysAhead(1)
->confirmed()
->count()}}
</td>
<td>
{{Transaction::->daysAhead(2)
->confirmed()
->count()}}
</td>
So, I'm dealing with Eloquent calls in my view. In reality there are scopes by sales person and by location, so there are 10-20 values being shown.
I can move this back into the Controller by having a very fat load of with statements, or of course put it into an Array in the controller, but that doesn't seem to help massively.
What is the best way to deal with this?

Answer 1

Keep your views as logic less as possible, don't clutter your controllers with logic either. This would, to most people mean stuffing all the logic into models. Again this isn't an approach that helps with writing re-usable and more importantly testable code.
Laravel's IoC container and dependency injection is incredibly powerful and should be utilised to structure your applications in a testable way.
I can understand why you want to pass the query object around as well, this is something I used to do in my models. It seems to make sense however it quickly becomes apparent that creating a rigid query builder using a powerful query builder will create some quantity of wet code.
My suggestion would be to keep your model as slim as possible, use them to create relationships, set eloquent properties, validation rule arrays and nothing more. Abstract all logic into a repository based on an interface. Why? Well, the interface can be bound through the IoC to the class it should resolve to meaning that it can be dependency injected and swapped out easily (Mockery for example) whilst maintaining structural integrity in any replacements you may want to build (a Mongo, CouchDB etc. implementation for example).
namespace Repositories;
interface TransactionInterface {
public function findAll();
public function findById($id);
public function findByDaysAhead($start = 0, $end = 1)
}
And for the repository
namespace Repositories;
use Transaction;
class TransactionEloquent implements TransactionInterface {
public function findAll()
{
return Transaction::all();
}
public function findById($id)
{
$transaction = Transaction::find($id);
if ( ! $transaction )
{
throw new Exception("Transaction not found");
}
return $transaction;
}
public function findByDaysAhead($start = 0 , $end = 1)
{
// Create one query to return all the data you need
}
}
You can then bind this repository either in a new custom ServiceProvider or in your routes.php.
App::bind('Repositories\TransactionInterface', 'Repositories\TransactionEloquent');
Now you can dependency inject into your controller the interface that will resolve to your eloquent implementation. If you write a different repository implementation you can simply rebind it to the interface meaning it'll be used wherever the interface is injected (Mockery classes for example)
class ApplicationController extends BaseController {
public function __construct(Repositories\TransactionInterface $interface)
{
$this->repo = $interface;
}
public function getIndex()
{
return View::make('index', array('transactions' => $this->repo->findAll());
}
}
In your view you would only require a simple loop over your data and outputting, no logic required.
Obviously you can put as much logic as you like in the repository and as you can see your controllers, models and views fulfil only the responsibility they are intended for (OOPS Single Responsibility Principle)
This is a very short answer to what is a very complex question. I hope this guides you someway to writing testable and reusable modular code in Laravel.
Some 'light' reading
Laravel 4's IoC container
Laravel 4's Service Providers
NetTuts article on building L4 and Backbone apps Ignore the backbone part, this is a great walkthrough on L4's IoC bindings.
Where to place files etc.
Following PSR-0 specifications I would end up with a structure like this
- app
- {name of app}
- Repositories
* TransactionInterface.php
* TransactionEloquent.php
The namespaces for these two files would now be namespace {name of app}\Repositories
In composer you can add this to the autoload object :
"psr-0": {
"{name of app}" : "app/"
}
This will add all PSR-0 compatible namespaces to the autoloader, when you make changes you can use
composer dump-autoload
to rebuild the autoloader and include your new files (not always required but is better and faster than composer update constantly).
How many repositories?
I usually end up with 1+ repositories per model. For example I have a backbone collection of models and individual models in the front end.
Using Backbone.sync(param, collection) would always utilise a repo that handles input as an array of models. Where as Backbone.sync(param, model) would utilise a repo that handled a single model being sent. I would also have two Laravel resource controllers to handle this as well.
Service Providers
I place these in my application folders route, my app is called "MFL" in this instance
- MFL
- Repositories
- MFLServiceProvider.php
I add this to my service providers array in config\app.php
namespace MFL;
use Illuminate\Support\ServiceProvider;
class MFLServiceProvider extends ServiceProvider {
public function register()
{
// Register bindings here, don't use other service providers here
// you can't be sure they are loaded as of yet
$this->app->bind('MFL\Repositories\TransactionInterface', 'MFL\Repositories\TransactionEloquent');
}
public function boot()
{
// Do anything else here with assurance all service providers are
// fully loaded and the application is ready
}
}
Using this method, you don't pollute routes.php with IoC bindings and you can logically partition all your code into services. This is my preferred method for the latter reason.

Answer 2

There is a 3rd option in view composers. At the most basic level these are included in routes.php but I like to break them out by view path so composers/transactions.php would handle all the views in views/transactions like 'transactions.dashboard'. Given that as a view then the composer would be...
View::composer('transactions.dashboard', function ($view)
{
$view->day0_count = Transaction::->daysAhead(0)
->booked()
->count();
}
$day0_count is now available in the view.
<td>{{ $day0_count }}</td>