laravel 5.0 Zastosowanie Struktura

Question

Buduję REST API korzystając laravel 5.

Starając się zachować kontrolerów HTTP jest możliwie jak najmniejszy, więc używam warstwie usług (i repozytoriów), aby obsłużyć najbardziej logiki.

Ponieważ większość kontrolerów ma podobne metody (np. show, index, update) Napisałem kilka cech, które obsługują każdy z nich. Ponieważ rozmawiają bezpośrednio z usługą, mogę je ponownie wykorzystać dla każdego kontrolera.

Na przykład:

<?php namespace API\Http\Controllers\Restful; 

trait UpdateTrait 
{ 
    protected $updater; 

    public function update($itemID) 
    { 
     if (!$this->updater->authorize($itemID)) { 
      return response(null, 401); 
     } 

     if (!$this->updater->exists($itemID)) { 
      return response(null, 404); 
     } 

     $data = $this->request->all(); 
     $validator = $this->updater->validator($data); 

     if ($validator->fails()) { 
      return response($validator->messages(), 422); 
     } 

     $this->updater->update($itemID, $data); 

     return response(null, 204); 
    } 
} 

Ponieważ wszystkie kontrolery posiadają te same cechy, wszystkie one mogą polegać na jednym interfejsie.

Na przykład:

<?php namespace API\Services\Interfaces; 

interface UpdaterServiceInterface 
{ 
    public function validator(array $data); 
    public function exists($itemID); 
    public function update($itemID, array $data); 
    public function authorize($itemID); 
} 

Jednak to powoduje kilka problemów z automatycznego wstrzykiwania zależności.

1) muszę używać kontekst świadomy Oprawa:

$this->app->when("API\Http\Controllers\ThingController") 
      ->needs("API\Services\Interfaces\UpdateServiceInterface") 
      ->give("API\Services\Things\ThingUpdateServiceInterface") 

To nie jest problematyczna w sobie - mimo że nie prowadzi do pewnego dość dużego kodu Service Provider, który nie jest idealny. Oznacza to jednak, że nie mogę użyć metody iniekcji, ponieważ automatyczna zależność wydaje się nie działać dla metod kontrolera podczas używania kontekstowego wiązania: Właśnie otrzymuję komunikat o błędzie.

Oznacza to, że konstruktor kontroler musi obsługiwać wszystkie wstrzykiwania zależności, który jest dość niechlujny:

class ThingsController extends Controller 
{ 
    use Restful\IndexTrait, 
     Restful\ShowTrait, 
     Restful\UpdateTrait, 
     Restful\PatchTrait, 
     Restful\StoreTrait, 
     Restful\DestroyTrait; 

    public function __construct(
     Interfaces\CollectionServiceInterface $collection, 
     Interfaces\ItemServiceInterface $item, 
     Interfaces\CreatorServiceInterface $creator, 
     Interfaces\UpdaterServiceInterface $updater, 
     Interfaces\PatcherServiceInterface $patcher, 
     Interfaces\DestroyerServiceInterface $destroyer 
    ) { 
     $this->collection = $collection; 
     $this->item = $item; 
     $this->creator = $creator; 
     $this->updater = $updater; 
     $this->patcher = $patcher; 
     $this->destroyer = $destroyer; 
    } 
} 

To nie jest dobry - to trudne do testowania i wszystkie te zależności mają dostać instancja, nawet gdy używa się tylko jednego z nich.

Ale nie mogę wymyślić ładniejszego sposobu obejścia tego.

Mogę użyć bardziej szczegółowego interfejsu, np. ThingUpdateServiceInterface, (wtedy nie potrzebowałbym wiązania kontekstowego i mógłbym wstrzyknąć bezpośrednio w cechy), ale wtedy miałbym wiele interfejsów, które różnią się tylko nazwą. Co wydaje się głupie.

Inną alternatywą, o której myślałem, było użycie wielu mniejszych kontrolerów, więc Things\UpdateController i Things\ShowController - w ten sposób niepotrzebne zależności nie będą tworzone za każdym razem.

A może próba oderwania się od używania cech jest złym sposobem robienia rzeczy. Cechy czasami wydają się być potencjalnie anty-wzorem.

Każda rada byłaby doceniona.

Answer 1

Twój kod wygląda świetnie i dobrze się uogólnia.

Chciałbym zasugerować tę opcję korzystania z fabryki do tworzenia usług, a nie predefiniować wszystkich zastrzyki zależności.

interface UpdateServiceInterface { 
    public function action($itemID); 
    //.... 
} 

class ThingUpdateServiceInterface implements UpdateServiceInterface { 
    public function action($itemID) 
    { 
     // TODO: Implement exists() method. 
    } 
} 

class ApiServiceFactory { 

    protected $app; 

    public function __construct(Application $app) { 
     $this->app = $app; 
    } 

    public function getUpdateService($type) { 
     if ($type == 'things') 
      return $this->app->make('ThingUpdateServiceInterface'); 
    } 

    public function getCreateService($type) { 
     if ($type == 'things') { 
      //same idea here and for the rest 
     } 
    } 

} 




class ApiController { 

    protected $factory; 
    protected $model; 

    public function __construct(ApiServiceFactory $factory) { 
     $this->factory = $factory; 
    } 

    public function update($data) { 
     $updater = $this->factory->getUpdateService($this->model); 
     $updater->action($data); 
    } 
} 

class ThingsController extends ApiController { 
    protected $model = 'App\Thing'; 
} 

jaka jest idea tego wszystkiego jest:

• podstawowy ApiController że posiada wszystkie metody: Update, Insert, Delete ...
• siebie kontroler dla określonego obiektu przedłuży kontroler api i nadpisać model $ z pełną nazwą modelu.
• w działaniu kontrolera używa fabryki do tworzenia usługi dla tego konkretnego obiektu.
• po utworzeniu usługi wykorzystuje ją do pożądanego działania.

• można utworzyć ogólne działanie dla działania, jak

  DeleteServiceInterface 
  

będą realizowane przez

class GeneralDeleteService implements DeleteServiceInterface { 
      public function delete($id){......} 
    } 

w fabryce, kiedy poprosić o tym DeleteService jeśli nazwa nie jest przekazywana więc zwróci domyślną usługę

nadzieję, że ten post nie będzie "TLDR"