Interface name already in use when using Repository pattern - php

I'm adapting repository pattern in a laravel application by creating the interface of a repository for a given model under the namespace of App\Repositories\Interfaces, and then creating the implementation class under the namespace App\Repositories, after that i bind the interface to the class in RepositoryServiceProvider.
Everything was going fine at first, but when I've created repository files for Grade model and trying to do php artisan route:list, or accessing a grade/ route I get this:
Symfony\Component\Debug\Exception\FatalErrorException thrown with message "Cannot declare interface App\Repositories\Interfaces\GradeRepositoryInterface, because the name is already in use"
Ok!, seems obvious, change the interface name and your good to go!, well NO.
the same error is raised with the same new interface name.
changing the namespace does not work either!.
I was running composer dump-autolod after changes.
Interface declaration:
use App\Models\Grade;
use App\Repositories\Interfaces\BaseRepository;
interface GradeRepositoryInterface extends BaseRepository
{
public function get(int $id) : Grade;
public function edit(int $id, array $data);
public function delete(int $id) : bool;
}
I highly doubt that symfony, or laravel have GradeRepositoryInterface interface.
Any suggestions? (Hopefully solutions)

Changed the name like GradesRepositroyInterface, and composer dump-autoload again

Related

Dynamically Initiate a class in another's constructor in Laravel (or php)

To make it simple i have two classes:
class AddressController extends ApiController
{
private AddressRepository $addressRepository;
public function __construct(AddressRepository $addressRepository)
{
$this->addressRepository = $addressRepository;
}
//........
class CountyController extends ApiController
{
private CountyRepository $countyRepository;
public function __construct(CountyRepository $countyRepository)
{
$this->countyRepository = $countyRepository;
}
//........
As you can see I'm extending the ApiController class and use dependency injection for both (county/address) repository.
My question is how to refactor it in a away everytime i extend from the ApiController, it create the repository property with the proper namespace.
Hi I suggest to do some tweaks on your Laravel Stub, which can fulfill your requirement.
On publishing Laravel Controller from command, you can customize your namespace and the stuffs you require in controller.
You can publish your current stub file using artisan command
php artisan stub:publish
for more https://laravel-news.com/customizing-stubs-in-laravel

Extending the class with an interface AkeneoPimClientInterface?

How to extend generated command in Symfony with use Akeneo\Pim\AkeneoPimClientInterface ?
I have generated a command using php app/console generate:command and I got this class:
class AppTriggerBuildCommand extends ContainerAwareCommand
Then developed it to the point when I need all the categories from the API. Seamlessly it is really an easy question, how can I use AkeneoPimClientInterface in the command.
I want to use it something like this.
$categories = $this->apiClient->getCategoryApi()->all();
And the apiClient in here comes inside the _contruct metod
public function __construct(AkeneoPimClient $apiClient, AkeneoLocaleMapper $mapper) {
$this->apiClient = $apiClient;
$this->mapper = $mapper;
}
And in use
use Akeneo\Pim\AkeneoPimClientInterface as AkeneoPimClient;
But when I tried to put it inside the _construct method in a command it want to use the parent _construct and it just can't see the generated command.
Could anyone help me ?
php app/console trigger build -vvv
[Symfony\Component\Console\Exception\CommandNotFoundException]
Command "trigger" is not defined.
Exception trace:
() at /var/www/html/iclei/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:526
Symfony\Component\Console\Application->find() at /var/www/html/iclei/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:94
Symfony\Bundle\FrameworkBundle\Console\Application->find() at /var/www/html/iclei/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:190
Symfony\Component\Console\Application->doRun() at /var/www/html/iclei/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:84
Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /var/www/html/iclei/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:117
Symfony\Component\Console\Application->run() at /var/www/html/iclei/app/console:27
Since you extend the ContainerAwareCommand you have access to Symfony's Service Container to fetch the client like this (you might have to replace the fully qualified class name with a service id, I'm not 100% sure):
$this->container->get('Akeneo\Pim\AkeneoPimClientInterface');
If you want to use the constructor (which I encourage you to do), you are almost there. You just have to also call the parent constructor as well:
public function __construct(AkeneoPimClient $apiClient, AkeneoLocaleMapper $mapper)
{
parent::__construct();
$this->apiClient = $apiClient;
$this->mapper = $mapper;
}
Both ways should work, but the latter allows you to move away from the ContainerAwareCommand to the more generic ContainerCommand, which will help you with Symfony 4 where services in the container will be private by default and therefore you can not just simply get them from the container like in the first version.
edit regarding the command name: You can specify the name of your command as argument to parent::__construct() and also set it via the configure() method, you need to override. In there you can just call, e.g. $this->setName('trigger-build');. Be careful not to use spaces, as Symfony will treat those as separate arguments. So trigger is the name of the command and build is the first argument you "feed" to the command.

Use of service providers within controllers in Laravel 5.2

As for the title I've googled about two hours searching for a efficient answer and read repeatedly the official documentation, but without any step further, considering I'm relatively new to the framework. The doubt arise while searching for a correct way to share some code between controllers and i stumbled in service providers, so:
I've created say a MyCustomServiceProvider;
I've added it to the providers and aliases arrays within the app.php file;
finally I've created a custom helpers class and registered it like:
class MyCustomServiceProvider extends ServiceProvider
{
public function boot()
{
//
}
public function register()
{
$this->app->bind('App\Helpers\Commander', function(){
return new Commander();
});
}
}
So far, however, if I use that custom class within a controller I necessarily need to add the path to it through the use statement:
use App\Helpers\Commander;
otherwise I get a nice class not found exception and obviously my controller does not his job.
I suspect there's something which escapes to me on service providers! :-)
So far, however, if I use that custom class within a controller I
necessarily need to add the path to it through the use statement:
`use App\Helpers\Commander;`
otherwise I get a nice class not found
exception and obviously my controller does not his job.
Yes, that's how it works. If you don't want to use the full name, you can use a Facade instead.
Create the Facade class like this:
class Commander extends Facade
{
protected static function getFacadeAccessor() { return 'commander'; }
}
register the service:
$this->app->singleton('commander', function ($app) {
return new Commander();
});
add the alias to your config/app.php:
'aliases' => [
//...
'Commander' => Path\To\Facades\Commander::class,
//...
],
and use it like a Facade:
\Commander::doStuff();
On why your code still works, even when you remove the bind:
When you type-hint a parameter to a function, and Laravel does not know about the type you want (through binding), Laravel will do its best to create that class for you, if it is possible. So even though you didn't bind the class, Laravel will happily create a instance of that class for you. Where you actually need the binding is when you use interfaces. Usually, you'd not type-hint specific classes but a interface. But Laravel can not create a instance of an interface and pass it to you, so Laravel needs to know how it can construct a class which implements the interface you need. In this case, you'd bind the class (or the closure which creates the class) to the interface.

Laravel error interface class does not exist

I am very new to "Advanced Laravel" so to speak, however I do know most of the basics and I am trying to understand what namespacing, interfaces and repositories is all about, since I came across it not so long ago.
However, I am getting the following error, and I have no idea what I am doing wrong:
Class app\models\Interfaces\CategoriesInterface does not exist
Below is my code:
Routes.php
App::bind('App\Models\Interfaces\BaseInterface', 'App\Models\Repositories\BaseRepository');
CategoriesController.php
<?php
use app\models\Interfaces\CategoriesInterface;
class CategoriesController extends BaseController
{
protected $categories;
public function __construct(CategoriesInterface $categories)
{
$this->categories = $categories;
}
BaseInterface.php
<?php
interface BaseInterface
{
public function all();
}
CategoriesInterface.php
<?php namespace App\Models\Interfaces;
interface CategoriesInterface extends BaseInterface { }
CategoriesRepository.php
<?php namespace app\models\Repositories;
use App\Models\Interfaces\CategoriesInterface;
use Categories;
class CategoriesRepository implements CategoriesInterface
{
public function all()
{
$categories = $this->categories->all();
return $categories;
}
}
EloquentCategoriesRepository.php
<?php namespace app\models\Repositories;
use App\Models\Interfaces\CategoriesInterface;
class EloquentCategoriesRepository implements CategoriesInterface {
public function all()
{
return Categories::all();
}
Try name spacing the classes/interfaces properly. EloquentCategoriesRepository.php and CategoriesRepository are having app instead of App in the namespace. And CategoriesController too needs to use App\.. not app\...
I see you are trying to implement the repository pattern, which at first it might seem a bit 'advanced' but it's actually pretty simple.
So the basic idea is to abstract the data layer of your application with the database to make your transitions from one DBS to another(ex. Mysql to Mongo).
In other words your are trying to make the business logic of your application independent to the data layer (Where you query your collections/instances), so when you reach a point that you might want to change your database you can just implement another repository. The Interfaces are there to provide a contract between your application and the data layer.
Laravel implementation of the repository pattern it's pretty straight forward.
Create your interface
Create your interface's repository (actual implementation)
Bind the repository using a service provider class (Or in your case App::bind)
Instantiate the dependency in to your controller using the repository
Don't forget to auto load your namespaces using psr-04.
In your case I think the problem is you are not autoloading the namespace.
Also CategoriesRepository.php & EloquentCategoriesRepository.php are both Eloquent repositories and will return Eloquent collections. To return an array of stdClass (standar PDO) you will have to use the \DB facade.
If my answer does not cover you please take a look here

IoC and interface binding catch 22

So in trying to implement IoC, DI, etc. in Laravel 4, I've hit a wall. Either I'm misunderstanding something or doing something horribly wrong, not sure which...
So I have a class Person ("business class", not a model or library):
namespace Entities;
use Interfaces\Person as PersonInterface;
class Person implements PersonInterface {...}
a factory which has:
use Interfaces\Person;
...
App::singleton('user', function($app) {
...
$user_object = new Person();
...
});
and in the aliases array:
'Interfaces\Person' => 'Entities\Person'
Problem is that doesn't work because the Person class can't implement its interface because the interface is bound back to the Person class:
Entities\Person cannot implement Entities\Person - it is not an interface
I seem to be caught in a catch 22 of using IoC and interfaces in the application preventing the classes from actually instantiating.
Don't know if it's relevant, but putting
App::bind('Interfaces\Person','Entities\Person');
in the routes.php files doesn't seem to do anything (but putting it in the aliases array does). Surely I'm doing something wrong here. Any ideas?
Maybe I can help. To bind an interface to the IoC, you want to have an interface and an implementation of the interface. It looks like you have that step correct. You also want to create a service provider. More info on that here: http://laravel.com/docs/ioc#service-providers
Remove any bindings you have from the routes.php file. The service provider is what binds the route, and config/app.php registers it in the IoC as described more fully below.
Your service provider might look something like this:
File Name: ServiceProviders/PersonServiceProvider.php
<?php namespace ServiceProviders;
use Illuminate\Support\ServiceProvider;
use Entities\Person;
class PersonServiceProvider extends ServiceProvider {
/**
* Register the binding.
*
* #return void
*/
public function register()
{
$this->app->bind('Interfaces\Person', function()
{
return new Person();
});
}
}
Once the service provider is created, register it in the config/app.php file as follows:
'ServiceProviders\PersonServiceProvider',
Don't use the aliases. This is used for registering the aliases of facades, which is not what you're attempting to do here if I understand your question correctly.
Lastly, to follow the generally accepted Laravel naming conventions, I'd suggest naming the interface file "PersonInterface.php" and its interface "interface PersonInterface." Similarly, the implementation file might be called "EloquentPerson.php" and the "class EloquentPerson extends PersonInterface". This assumes you're using Eloquent. It's similar to what you have, but I think the class and interface names could make it more readable with those small tweaks.

Categories