Laravel Facade Implementation - laravel

I am confused as to how to use the cache in Laravel. I can either use the Cache facade and do something like …
use Cache;
public function someMethod()
{
Cache::remember('users', 60 , function() {
return DB::table('users')->get();
});
}
Or I could use something like this …
use Illuminate\Contracts\Cache\Repository;
protected $cache;
public function __construct(Repository $repository)
{
$this->cache = $repository;
}
public function someMethod()
{
$this->cache->remember('users', 60 , function() {
return DB::table('users')->get();
});
}
Both will implement the same method remember from vendor/laravel/framework/src/Illuminate/Cache/Repository.php
Repository class which implements vendor/laravel/framework/src/Illuminate/Contracts/Cache/Repository.php which I have included in the second method.
As per Laravel docs:
The Illuminate\Contracts\Cache\Factory and Illuminate\Contracts\Cache\Repository contracts provide access to Laravel's cache services. The Factory contract provides access to all cache drivers defined for your application. The Repository contract is typically an implementation of the default cache driver for your application as specified by your cache configuration file.
However, you may also use the Cache facade, which is what we will use throughout this documentation. The Cache facade provides convenient, terse access to the underlying implementations of the Laravel cache contracts.
So can I conclude that both the approach are same. The Cache Facade provides me a cleaner implementation, that's it.

You would get the same result in your application. It's the same but not the same.
In your second approach you are using dependency injection. Which makes it easier to write tests for your class. This way you get a better maintainable application.
Have a deeper look at dependency injection. Here is a nice article: Dependency Injection with Laravel’s IoC.

Related

How does a facade getFacadeAccessor() method work?

I am reading through the Laravel documentation to try and achieve a deeper understanding of the framework but I am having a bit of trouble with facades. I think I understand what they are, they are mostly used for convenience when accessing Laravels core.
My confusion is with this topic:
How does a facade work? (Specifically related to the getFacadeAccessor() method. Is this magic?)
Facades is another way to use classes without manually creating an object. They are just a shortcut to classes registered by Laravel container.
For example, this:
DB::
Makes absolutely the same as if you'd use the container:
app('db')->
So, DB:: facade is just a shortcut for app('db')->.
And yes, facades use the magic method __callStatic() which resolves an instance of a class and executes given method:
public static function __callStatic($method, $args)
{
$instance = static::getFacadeRoot();
if (! $instance) {
throw new RuntimeException('A facade root has not been set.');
}
return $instance->$method(...$args);
}

Loading classes only if function is called

I have one FrontendController that get all requests from frontend. As all URLs are like:
Route::get('/{slug}', 'FrontendController#index');
I need to use the same controller to get all Entities. My FrontendController looks like this:
use Auth;
use App;
use Cache;
use URL;
use Redirect;
use Session;
use Response;
use App\Country;
use App\I18n;
use App\User;
use App\CMS;
use App\CMSPageContent;
use App\Slugs;
use App\News;
...
...
use App\Http\Controllers\Controller;
I have several questions regarding this:
Are ALL these services injected in each execution of FrontendController. Because maybe I'm loading the entire code and It will make my page load slow.
If answer to previous question is yes, can I load a library only if one function is called?
Is it a good way to solve the slug problem? Because all URLs have one piece only for SEO reasons and I don't know other way to treat the routes.
It varies depending on how you are using the code. For example if you required the Auth login method, but nothing else, it would be a waste of resources to initialise a model or inject the model into that function.
For example say this is a function in my model
public function doSomething()
{
//Do stuff
}
I would like to call this function in my Controller. I have a few options, I could reference the model at the top of my controller
use App\MyModel;
I believe this doesn't actually initiate the model, it acts like a reference, so that when it is called, the system knows where to find it.
I could inject it into my function
public function myControllerFunction(\App\MyModel $model)
{
return $model->doSomething();
}
This uses the most resources due to the model being assigned to the $model variable, which is fine if you need the models eloquent for database actions and its functions. If you require just one function from that model then a static call would use less resources.
In your model make the function static
public static function doSomething()
{
}
Then in your controller you can call it like this
public function myControllerFunction()
{
return \App\MyModel::doSomething();
}
This would use the less resources and would clean up the code a bit as you wouldn't need to keep referencing your uses at the top of the controller

How does laravel 5 know which contract implementation I want to use?

I'm kind of confused of how to use contracts. I think that's because I haven't used unit-testing so that it's not obvious for me how contracts work.
Let's have look at this code:
use Illuminate\Contracts\Auth\Guard;
...
public function __construct(Guard $auth)
{
$this->auth = $auth;
$this->middleware('guest', ['except' => 'getLogout']);
}
public function postRegister(RegisterRequest $request)
{
// Registration form is valid, create user...
$this->auth->login($user);
return redirect('/');
}
So how do I know which class implements login method of contract in this line: $this->auth->login($user) ? And how can I change the class if I want to use my own?
In laravel 4 I wrote Auth::user() as an example and I used it everywhere in any controller and it worked. Now I should inject a contract inside a controller method and use it like $auth->user?
Also, If I get it right, contracts are used for making an abstraction. Okay, so, if I want to build a new interface for my own class and then have multiple classes that implement my interface, where should I write the code? I can't think of an example but lets imagine I need to implement an interface for enabling/disabling a lamp, and I have two methods like on() and off() and I have multiple ways to do that. Do I need to create new contract for that?
I hope I can make this a bit clearer for you...
Ad.1. You can check default binding at /vendor/laravel/framework/src/Illuminate/Foundation/Application.php (method registerCoreContainerAliases around line 792). If you want to create your own class or extend existing I recommend looking at How to extend Laravel's Auth Guard class? or http://laravel.com/docs/master/extending (this one is more about Laravel 4.x but might give you an idea).
Ad.2. Actually you can still use Auth::user() but I inject a contract in constructor or a method and call it like $this->auth->user or $auth->user.
Ad.3. I have a /app/Repositories folder where I put my interfaces and implementations, so to follow your example I would create subfolder Lamp and I would create LampInterface with on() and off() methods, then I would create something like Lamp.php that implements LampInterface. Next I would create a service provider in /app/Providers, like LampServiceProvider.php with binding:
namespace Apps\Providers;
use Illuminate\Support\ServiceProvider;
class LampServiceProvider extends ServiceProvider {
/**
* Register the application services.
*
* #return void
*/
public function register()
{
$this->app->singleton(
'App\Repositories\Lamp\LampInterface',
'App\Repositories\Lamp\Lamp'
);
}
}
After that I would register new service provider in /app/config/app.php and finally I can inject my interface like:
public function switchLampOn(App\Repository\Lamp\LampInterface $lamp)
{
$lamp->on();
}

ZF2: Injecting Session management into a service

I'm familiar with how to use the Session in ZF2, e.g.
$user_session = new Container('user');
$user_session->username = 'JohnDoe';
This is fine, but if I'm trying to persist session data in one of my business logic services I'd strongly prefer to inject a session management object/service into my service's constructor, like in this pseudocode:
class BusinessSvc{
protected $sessionSvc;
function __construct($sessionSvc){
$this->sessionSvc = $sessionSvc;
}
public function doBusinessLayerStuff(){
... do stuff ...
$this->sessionSvc->store('lastOrderNumber', '1234');
... do stuff ...
}
}
I would think the framework would provide this functionality, but I can't find it anywhere. I could always write my own, but didn't want to reinvent the wheel.
The answer was a lot simpler than I realized. Once instantiated, a Container instance itself can be injected into the business service and provide it with access to the session. If using phpunit to later test the service, the object could be mocked with an array or an instance of ArrayObject.
In Module.php's getServiceConfig method:
'MyModule\Service\BusinessService' => function($sm) {
// Container doesn't need to use this name but it seems sensible.
$container = new Container('MyModule\Service\BusinessService');
return new Service\BusinessService($container);
},

Make Doctrine use result cache by default

I'm binding Memcache to Doctrine and it seems I have to useResultCache explicitly in every query. Is it possible to make it true by default, with the ability to useResultCache(false) where it's not needed?
Create a wrapper class/function that explicitly sets useResultCache(true) and use that everywhere instead of the native function.
I know this question is old, but I'll write up the best answer that comes into my mind.
1) Abstract away your dependency to interface ( i.e. - use dependency injection pattern to inject EntityManager into your class that creates queries and use EntityManagerInterface instead )
Now, either:
a) [ Better, but longer ] Create a new composition-related implementation for EntityManagerInterface, that will proxy calls to original entityManager and will set result cache flag to true:
<?php
class CachedEntityManager implements EntityManagerInterface {
private $proxiedManager;
public function __construct(EntityManagerInterface $proxiedManager) {
$this->proxiedManager = $proxiedManager;
}
public function createQuery($dql = '') {
$query = $this->proxiedManager->createQuery($dql);
$query->useResultCache(true);
}
[... proxy all the calls forth to proxiedManager ...]
}
b) [ Not as good, but shorter ] Extend the EntityManager class and override the createQuery. Remember that this in general is not a good practice and you should definitely not write anything in that class anymore but instead refactor into a) :
<?php
class CachedEntityManager extends EntityManager {
public function createQuery($dql = '') {
$query = parent::createQuery($dql);
$query->useResultCache(true);
}
}
You can hack the Doctrine core a little by setting the default value of $_useResultCache to TRUE in \Doctrine\ORM\AbstractQuery. This will make all queries use the resultCacheDriver by default, and you can easily turn the cache off for individual queries using $query->useResultCache(FALSE)
It's a useful little hack that saves you a lot of typing, but be careful; I've found that the caching driver won't cache lazy-loaded associations that haven't been initialized (which is obvious now I think about it). Sometimes it's safer to just turn result caching on for each individual query.

Resources