1872 1805 1502 1845 1356 1259 1173 1360 1957 1504 1149 1572 1782 1151 1444 1947 1104 1412 1584 1777 1594 1852 1994 1673 1069 1623 1017 1778 1326 1333 1321 1426 1723 1964 1530 1843 1805 1798 1709 1423 1905 1139 1830 1853 1818 1179 1710 1838 1979 1763 1058 1899 1237 1892 1795 1063 1121 1019 1830 1149 1169 1016 1509 1235 1725 1514 1712 1334 1419 1732 1684 1654 1490 1686 1448 1781 1092 1320 1932 1960 1388 1307 1512 1826 1568 1234 1133 1541 1188 1314 1190 1521 1881 1407 1414 1589 1548 1954 1548 Response: Don’t Use Facades | PHPnews.io

PHPnews.io

Response: Don’t Use Facades

Written by Taylor Otwell / Original link on Jan. 13, 2014

This afternoon an article was posted to Reddit that cautioned users of Laravel to stop using “Facades”.

In the context of Laravel, Facades are what you are using when you make what appears to be a static call to a class. For example:

Route::get('/', 'HomeController@showWelcome');

However, as many of you are already aware, this call may be rewritten like so:

$app['router']->get('/', 'HomeController@showWelcome');

The code may be written easier way because, at their core, facades are syntactic sugar for service location. When you make a call to a Facade, the Facade resolves the underlying class out of the Laravel IoC container and calls the intended method on the instance. They provide a very terse, expressive syntax, while still maintaining the ability to test your code.

However, service location can lead developers into some bad architectural habits. For instance, since service location is very “easy”, it can lead to responsibility bloat in your classes. Generally, classes with small, focused responsibilities are to be desired since they are easier to understand, test, debug, etc. However, if you are using Facades to push to the queue, send an e-mail, and validate some data all within a single class, that class’ core responsibilities are obscured. It is concerned about way too many things.

It is possible to use Facades responsibly and keep your class responsibilities narrowly focused. However, some prefer the discipline that constructor injection provides. Constructor injection means that a class’ dependencies are injected via the constructor when that class is created. It is an explicit declaration of what that class needs, and therefore gives an idea as to what that class does.

Before today, injecting the underlying class behind a facade required some explicit bindings to be registered in the IoC container; however, starting today, it is now just as easy to inject your dependencies as it is to use a Facade. By simply type-hinting the class underlying the Facade, it will automatically be injected by the container when it is needed as a dependency.

For example, need an instance of the Session injected into a controller? Just do this:

<?php

class HomeController extends BaseController {

	public function __construct(Illuminate\Session\Store $session)
	{
		$this->session = $session;
	}

}

There is no longer any need to do any extra configuration. Since all controllers are automatically resolved by the Laravel IoC container, the session instance will automatically be injected. Injecting the class underlying the Facade is just as easy as using the Facade itself! If you love using Facades, keep on using them, just keep an eye on those class responsibilities! If you prefer constructor injection, it just got a heck of a lot easier!

If you’re not sure what class to type-hint, check out the Facade To Class Reference from the Laravel documentation.

Enjoy!

taylorotwell 15

« Full IoC & Unit Testing With Laravel - Unifying PHP »