I wanna ask about design pattern.
Why should I use dependency injection in constructor, not import it ('use statement')?
For example:
in my controller:
class AuthController extends Controller {
public function __construct(UserGateway $userGateway)
{
$this->userGateway = $userGateway;
}
public function doSomething()
{
$this->userGateway->foo();
}
}
Why don't use just like this instead?
use Acme\UserGateway;
class AuthController extends Controller {
public function doSomething()
{
UserGateway::foo();
}
}
Many thanks.
Assuming UserGateway is not laravel facade: here's the biggest advantage of injecting stuff this way: in the future, you might redefine what UserGateway actually is, and supply some other class (most often, it's subclass) instead of it like this:
$this->app->bind(UserGateway::class, function ($app) {
return new NewUserGateway();
});
This is extremely useful for overriding some parts of your code, especially if you're using same packages across multiple projects. And it does not require you to change the AuthController's code.
If UserGateway is a Facade, the only benefit you'll get is a better code navigation with you IDE, since it will know what class exactly are you referencing (assuming that you didn't re-bound it).
Related
I have to call the method of another controller.
I use following code to make a call.
app('App\Http\Controllers\ApiUserController')->getList();
This is working fine.
But I want to try using use function so that I dont have to repeat all line
use App\Http\Controllers\ApiUserController;
class MyMethods
{
public function index()
{
app('ApiUserController')->getList()
Did I made some mistake here?
Instead of using app function, you will need to go through OOP way like so:
use App\Http\Controllers\ApiUserController;
class MyMethods
{
public function index()
{
$apiUserController = new ApiUserController();
$apiUserController->getList();
However, as many people have mentioned here, it is not really the best practice to call a method of one controller from the another.
So if I were at your place, I would create a helper, register its alias in config and use that helper to get the list in both places.
I hope it helps
Calling controller from other controller or other objects is not a good practice. Here is a good article explaining why. Also "fat" controllers is less preferable than "thin" controllers.
You should define a service layer object with common logic and use it. Create a service object and register it with one of service providers.
namespace App\Providers;
use Illuminate\Support\ServiceProvider;
use App\Services\YourUserService;
class AppServiceProvider extends ServiceProvider
{
public function register()
{
$this->app->singleton(YourUserService::class);
}
}
After that you can use your service in DI style.
use App\Services\YourUserService;
class MyMethods
{
protected $userService;
public function __construct(YourUserService $userService)
{
$this->userService = $userService;
}
public function index()
{
$this->userService->foo();
}
}
Why should I use dependency injection?
I agree with the answer Learner has given above, however, I wouldn't recommend it in terms of code organisation and testability.
Looking at the code, I can see that you need to get list of users and thats why you have to call the api user controller from another controller. However, you can easily extract the logic out to a service or even a trait.
if you were to use a trait then you could do some thing like following,
trait ApiUser {
public function getList()
{
// get the list for users from api
}
}
//Then you can simply use this trait any where you want,
class SomeController
{
// correct namespace for ApiUser trait
use ApiUser;
}
Another way of doing it, which i love to use again and again depending on the scenario; is to stick with the principle of coding to interface not to implementation. That would be some thing like follow.
interface ApiUserInterface
{
public function getList();
}
class ApiUser implements ApiUserInterface
{
public function getList()
{
// logic to get users from api
}
}
Make sure that when application requires the interface, it knows where to find its implementation. If you using Laravel, then you could register your interface to class in AppServiceProvider
Once that's done, you can use this service any where you want as a contract.
class OneController
{
protected $apiUserContract;
public function __construct(ApiUserInterface $apiUserContract)
{
$this->apiUserContract = $apiUserContract;
}
public function index()
{
// You can retrieve the list of the contract
$this->apiUserContract->getList();
}
}
// you could also just typehint the contact in method without requiring
// it in constructor and it will get resolved out of IOC i.e. container
class AnotherController
{
public function index(ApiUserInterface $apiUserContract)
{
// You can retrieve the list of the contract
$apiUserContract->getList();
}
}
Let me know if you need further explanation and hope it helps
I'm using Laravel 5.5 and trying to get used to code by psr-2 standard (just started learning). I analyze all my code with Quafoo QA and go step by step fixing the errors and record them.
By using facades i get this error "Avoid using static access to class". Because of it i'm trying to avoid using them.
On my controller i have this code:
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
use App\Events\FileLoaded;
use Illuminate\Support\Facades\Input;
use Illuminate\Auth\Middleware\Authenticate;
use PhpOffice\PhpSpreadsheet\Shared\StringHelper;
use \Illuminate\Contracts\View\Factory as ViewFactory;
class LoadDataController extends Controller
{
public function index()
{
$viewfactory = app(ViewFactory::class);
return $viewfactory->make('LoadData/index');
}
//more code
}
Besides the View Facade i also use DB, Input, Validator and Storage
Is this the correct way, are there others?
You don't need to avoid Facades - they are a key part of the framework. But if you want to, you can use dependency injection to include the classes you need as arguments in the controller methods:
class LoadDataController extends Controller
{
public function index(ViewFactory $viewFactory)
{
return $viewfactory->make('LoadData/index');
}
//more code
}
Or if you need that in all the controller methods:
class LoadDataController extends Controller
{
private $viewFactory;
public function __construct(ViewFactory $viewFactory)
{
$this->viewFactory = $viewFactory;
}
public function index()
{
return $this->viewFactory->make('LoadData/index');
}
//more code
}
Of course, this doesn't actually change the functionality of the code you've written, it just rearranges it. I wouldn't take the word of the code analyzer you mentioned as something you are doing wrong. These are standard patterns to use in Laravel.
I have a question about using Trait and Interfaces in PHP.
A trait with foobar function
<?php
trait FoobarTrait
{
protected $foobar;
public function setFoobar($foobar)
{
$this->foobar = $foobar
}
public function getFoobar()
{
return $this->foobar;
}
}
The specific Interface to specify how to use Trait
<?php
interface FoobarInterface
{
public function setFoobar($foobar);
public function getFoobar();
}
I want use foobar feature in a class. What is the best way ?
It is necessary to implements with an interface and specify trait or it is an induced behavior ?
<?php
class FoobarClass implements FoobarInterface
{
use FoobarTrait;
}
Or this
<?php
class FoobarClass
{
use FoobarTrait;
}
Thank's for your reply and debate ;)
As it was correctly stated in the comments by #Federkun, "it depends". In my opinion mostly on how are you about to use your FoobarClass.
If it's an implementation of some kind of service that can have multiple implementations depending on external conditions (consider file system or S3 for handling user uploads, as an example), I would use FooBarInterface as I can then type-hint it in other places using the service.
If you wish to just avoid repeating yourself, you could use a trait and no interfaces. Or even a base abstract class AbstractFooBar { ... } to encapsulate the repeating code.
If you only have one implementation for getting and setting $fooBar - just put it all in the same class :)
I would like to decorate every controller action that I have in my project.
I would like to start a custom logger engine and stop it every time an action method is called.
Like this:
class HomeController
{
public function indexAction()
{
Logger:start();
someLogicInThere();
...
Logger:end();
}
}
I would like to automate that extending to some class or something like this.
My final class controller will look like this:
class HomeController extends ControllerDecorator
{
public function indexAction()
{
someLogicInThere();
...
}
}
BTW: the logger stuff doesn't really matter. My question is more a design pattern issue
Any great idea?
You can use the built-in methods beforeAction (http://www.yiiframework.com/doc/api/1.1/CController#beforeAction-detail) and afterAction (http://www.yiiframework.com/doc/api/1.1/CController#afterAction-detail), inside your ControllerDecorator.
This way you would be able to decorate every class tha extends ControllerDecorator.
ps: I'm assuming you are using Yii. Right?
Your problem is called Cross-cutting concern. One way to handle this is by Aspect-oriented programming.
You can fake this in PHP >= 5.4 with Traits:
trait Logger
{
public function indexAction()
{
echo 'logging before<br>';
parent::indexAction();
echo 'logging after<br>';
}
}
class HomeControllerBase
{
public function indexAction()
{
echo 'indexAction<br>';
}
}
class HomeController extends HomeControllerBase
{
use Logger;
}
$homeController = new HomeController();
$homeController->indexAction();
As an experiment I've automated this process of writing a base class:
https://github.com/bitworking/AOP
I would not really use this in production because it needs to much resources.
Better look into AOP frameworks that parses the doctype and caches the new created class.
Not tested:
http://go.aopphp.com/
https://github.com/AOP-PHP/AOP
Another way to handle cross cutting concerns is to use event driven programming. This does not separate it 100% like AOP but it's a more approved design pattern especially in PHP.
I have seen some similar questions but I have yet to find a good solution for this from the interface all the way to the controller.
My Problem:
I have a few different kinds of applications that will require restarts, each has its own logic for restarting the application(SSH,API calls, etc.). I have set up an interface because although different logic, they all will need some similar functions. I have also created 3 classes, one for each app that implements that interface. where I am having issues is understanding the best way to keep the logic as abstracted from the controller as possible.
Some Questions:
Should I also be creating an Abstract class?
Should this be one controller that handles all types and chooses the correct one?
do I simply inject the different classes into the controller?
Code:
RestartInterface.php
<?php namespace Application\Service\Restart;
interface RestartInterface {
public function start();
public function stop();
public function restart();
}
example of implementing class:
<?php namespace Application\Service\Restart\AppOne;
use Application\Service\Restart\RestartInterface;
class AppOneRestart implements RestartInterface {
public function start() {
}
public function stop() {
}
public function restart() {
}
}
How could I use a service provider to keep this as modular as possible?
What is the best practice in this situation, I would like to be able to use many or as little restart implementations as I want.
thanks!
An abstract class is a way to create a base class you don't need your developers instantiating directly because, usually, there is still missing code from it, like, methods were not fully implemented. So you create an abstract which implements the common methods of your concrete restart classes
abstract class Restart {
public function restart() {
}
}
And then you implement one by one of those classes extending your abstract and creating the missing methods:
class AppOneRestart extends Restart implements RestartInterface {
public function start() {
}
public function stop() {
}
}
Option 1
If your whole application can use a single implementation of it and you just need the ability to swap from one to another, because your business somehow changed, a simple binding will do the trick:
App::bind('RestartInterface', 'AppOneRestart');
Option 2
If during a request you might need one or another, you probably will need to implement the Factory pattern: http://en.wikipedia.org/wiki/Factory_method_pattern, so you inject the factory in your controller:
class RestartApiController extends Controller {
public function __construct(RestartFactory $factory)
{
$this->restart = $factory->make('api');
}
}