2013-04-10 10 views
14

Zastanawiam się, gdzie umieścić Laravel Event Listeners i Handlers. Ktoś mi powiedział, że mogę je umieścić wszędzie. To właśnie próbowałem do tej pory.Gdzie umieszczam detektory zdarzeń i procedury obsługi?

# listeners/log.php 
<?php 
Event::listen('log.create', '[email protected]'); 

# handlers/LogHandler.php 
<?php 
class LogHandler { 
     public function create(){ 
      $character = new Character; 
      $character->name = "test"; 
      $character->save(); 
    } 
} 

# controllers/MainController.php 
    public function test(){ 
     Event::fire('log.create'); 
     return "fired"; 
    } 

# start/global.php 
ClassLoader::addDirectories(array(
    app_path().'/commands', 
    app_path().'/controllers', 
    app_path().'/models', 
    app_path().'/database/seeds', 
    app_path().'/libraries', 
    app_path().'/listeners', 
    app_path().'/handlers', 
)); 

Odpowiedz

22

mam zamiar założyć, że pytasz to dlatego, że nie pracujesz, zamiast na potwierdzenie czegoś, że masz pracę.

Chociaż jest prawdą, że można umieścić słuchaczy zdarzeń w dowolnym miejscu, należy się upewnić, że faktycznie zostaną uwzględnione - Laravel nie szuka w poszukiwaniu kodu źródłowego.

Moje ulubione miejsce dołączania takich plików to start/global.php. Jeśli spojrzysz na dolną część pliku, zobaczysz, gdzie są zawarte filtry, możesz zrobić to samo, aby uwzględnić swoich słuchaczy. Byłoby to najczystsze, aby utrzymać je wszystkie w jednym pliku słuchaczy, podobnie jak wszystkich swoich tras znajdują się w jednym pliku trasy ...

# start/global.php 
require app_path().'/filters.php'; 
+0

Dziękuję, to zadziałało dla mnie! – Strernd

+5

+1 Dobra sugestia. Zastanawiam się jednak, czy istnieje inna interesująca alternatywa ... może tworzenie folderu "app/listeners" dla słuchaczy klasy ...? I dodanie 'app_path(). '/ Listeners',' to' ClassLoader :: addDirectories (array ('at' app/start/global.php' ...? –

+0

Myślę, że to działałoby dla handlerów, ale ponieważ słuchacze nie są tak naprawdę klasami, o których nie sądzę, że kiedykolwiek zostaną załadowane? –

12

My osobista opinia to, że jest złą praktyką w ogóle do ryczałtu detektorów zdarzeń w jedno miejsce. Oczywiście, dziś potrzebujesz tylko 2 lub 3, ale zakres można dodać do dowolnego projektu w dowolnym momencie, możliwe dodanie dużo więcej.

Zamiast tego zazwyczaj tworzę katalog pod katalogiem app (np. app/CompanyName) i umieszczam w nim cały mój kod aplikacji. Powiedzieć laravel jak znaleźć swoje pliki, możesz zaktualizować swój composer.json llike to:

"autoload": { 
    "classmap": [ 
     // ... 
    ], 
    "psr-4": { 
     "CompanyName\\" : "app/" 
    }, 
} 

Po tym, należy uruchomić composer dump-autoload.

Teraz można tworzyć katalogi przestrzeni nazw wewnątrz niestandardowym katalogu aplikacji, jak app/CompanyName/Events/ i móc segregować swoje detektory zdarzeń na grupy, które mają sens, i umieścić je wewnątrz usługodawcy, na przykład:

<?php namespace CompanyName/Events; 
// File: app/CompanyName/Events/LogEventsProvider.php 

use Illuminate\Support\ServiceProvider; 

class LogEventsProvider extends ServiceProvider 
{ 
    public function register() 
    { 
     Event::listen('log.create', 'CompanyName/Events/[email protected]'); 
    } 

    public function create() 
    { 
     // ... 
    } 
} 

teraz można dodać tego usługodawcę do app/config/app.php i być dobrze iść, i wszystkich związanych z nimi detektorów zdarzeń w jednym pliku, a wszystkie detektorów zdarzeń w jednym katalogu, jeszcze oddzielne tak, że jeśli coś poszło nie tak z jednym z nich, nie musisz przeszukiwać WSZYSTKICH z nich, aby znaleźć miejsce, w którym wystąpił błąd.

NB: Nie wymyśliłem tego jako praktyki, ale znalazłem ją gdzieś po drodze. Ja jednak nie pamiętam, gdzie to było.

+0

Czy to dobra praktyka, ogólnie rzecz biorąc, rejestrowanie się i słuchanie z tą samą klasą Provider? Czy nie byłoby lepiej mieć dedykowaną klasę słuchaczy? – kitensei

+0

Nie , masz rację, lepiej jest rozdzielić te dwa.Może to umożliwić łatwiejsze testowanie detektorów zdarzeń bez bałaganu od rejestracji usługodawcy wiążącego.I zawarłem to tylko powyżej jako ilustrację, jak rejestracja detektora zdarzeń może To jest zasadniczo mój punkt powyżej - zarejestruj słuchaczy wewnątrz usługodawcy, a nadal możesz zachować całkowitą kontrolę nad _where_ rzeczywistą metodą, którą jest "słuchanie". –

Powiązane problemy