10 \ November 2018 \ http://www.phparch.comMaintaining Laravel Applicationsthere’s no need to inject a BaseController as the framework
already inherits from a Controller^3 you may customize.
As for models or other classes, Laravel uses traits more than
inheritance to decorate classes with additional functionality.
SoftDelete is a common example. Traits may be a better fit for
your code as well as more closely align with the framework.
This makes the code easier to understand and therefore easier
to maintain.
Similar to injecting inheritance, developers also copy entire
classes to extend or overwrite functionality. This is incredi-
bly difficult to upgrade. Not only do you have to track what
changed in the new version, but how it differed in the old
version, and also what customizations you made. It’s like
putting Humpty Dumpty back together again.
Laravel provides plenty of hooks for overriding core func-
tionality of classes and traits. Overriding individual methods
is a better alternative than inheritance. For example, instead
of copying the entire AuthenticatesUser trait to add additional
login constraints, you can simply override the credentials
method as in Listing 1.
The goal is to be minimally invasive. This way when the
core code inevitably changes, you only have small manageable
pieces to track instead of entire classes. When you do over-
ride a core method, consider adding an @override annotation
to the DocBlock. This is a good way to indicate core changes
and makes it easier to search for them when upgrading.
Note: Events are an even better way to extend core func-
tionality. Laravel fires events for all sorts for things: log in,
log out, saving model data, etc. Check the documentation
for more details^4.Overusing Facade
Fifty-seven percent of applications abuse facades. Facades
are already a controversial topic within the Laravel commu-
nity. A majority of applications use facades when they don’t
need to, which adds fuel to the fire. The biggest offense occurs
within controllers and middleware abusing the Request, Auth,
and Session facades.
Consider the code in Listing 2 for a controller action.
It uses the facades to access request data, the authenticated
user, and the session. However, both controllers and middle-
ware have a Request object injected. Instead of using facades
we can get everything through the Request object (see List-
ing 3). This not only prevents facade abuse but helps lower
coupling which is good for design and testing.Native Features
Laravel is a full-stack, full-featured web framework. Before
you write any custom code, do a few Google searches to see if3 Controller: https://phpa.me/laravel-master-controller
4 more details: https://phpa.me/laravel-auth-events
the code exists natively. I can’t tell you how many times search
results have lead me right back to the Laravel documentation^5.
If you have time one afternoon, I would recommend reading
through the documentation. It is well written and organized
to read almost like a book.
Even so, not all features are documented. Nevertheless,
they probably exist. Too often developers jump straight
into coding their own features or adding a package. All of
5 Laravel documentation: https://laravel.com/docs/5.Listing 3- public function store(Request $request)
- {
- $data = $request->only('product_id', 'token');
- if ($request->user()) {
- $data['email'] = $request->user()->email;
- }
- $request->session()
- ->put('token', $request->input('token'));
- // ...
- }
Listing 2- public function store()
- {
- $data = Request::only('product_id', 'token');
- if (Auth::check()) {
- $data['email'] = Auth::user()->email;
- }
- Session::put('token', Request::get('token'));
- // ...
- }
Listing 1- <?php
- class LoginController extends Controller
- {
- use AuthenticatesUsers;
- // ...
- /**
- @override
- */
- protected function credentials(Request $request) {
- return $request->only($this->username(), 'password')
- ['active' => 1];
- }
- }