Schemat poleceń w aplikacjach php: jak radzić sobie z działaniami kontrolera?

Question

Myślę, że jest to raczej ogólne pytanie (więc nie php ograniczone) w odniesieniu do ddd i wzorca polecenia.

Załóżmy, że wykonuję CreatePostCommand z poziomu działania create mojego kontrolera, polecenie zostanie obsłużone i ostatecznie zostanie pomyślnie wykonane. Jaki jest właściwy sposób powiadomienia kontrolera, która odpowiedź ma zostać zwrócona w przypadku niepowodzenia lub sukcesu polecenia? Biorąc pod uwagę, że obsługa komend uruchomi zdarzenie związane z daną domeną, mógłbym podłączyć kontroler do zdarzenia, ale to wydaje się dość kłopotliwe, również nieodpowiednie w każdej sytuacji (np. Post mógł zostać utworzony gdzieś indziej, a kontroler naprawdę nie o tym wiedz :)).

public function createAction($title, $content) 
{ 
    $this->commandBus->execute(new CreatePostCommand($title, $content); 

    $this->render('…'); // what if the command execution failed? 
} 

Jakieś przemyślenia na ten temat?

Answer 1

Wydaje mi się, że jeśli naprawdę próbujesz przestrzegać schematu poleceń DDD, musisz potraktować magistralę poleceń jako pożar i zapomnieć o procesie asynchronicznym, który może zająć dużo czasu.

Rozważ natychmiastowe przekierowanie do kontrolera weryfikatora poleceń. Od weryfikatora komend zależy aktywne sprawdzenie statusu polecenia i sprawdzenie, czy zadziałało.

W większości przypadków polecenie zakończy się pomyślnie, a następnie Twój weryfikator może ponownie przekierować, aby kontynuować normalny przepływ.

Jeśli polecenie nie powiedzie się, wówczas weryfikator wstawi odpowiedni komunikat o błędzie.

Jeśli polecenie jest w toku, można wykonać całą pętlę przekierowania, informując użytkownika, że ​​polecenie jest w toku.

Coś jak:

// Execute the command 
$command = new CreatePostCommand($title, $content); 
$this->commandBus->execute($command); 

return redirect '/command-verifier/' . $command->getId(); 

// The verification action 
public function verifyCommandAction($commandId) 

$commandStatus = $this->commandBus->getStatus($commandId); 

if ($commandStatus == SUCCESS) redirect to all is well; 

if ($commandStatus == FAILED) then oops; 

if ($commandStatus == IN_PROGRESS) then maybe pause a bit and redirect again while keeping the user informed. 

Oczywiście jest sporo macha ręką dzieje, ale myślę, że jest to najbardziej ogólne podejście zwłaszcza z php gdzie każde żądanie rozpoczyna się od punktu zerowego.

Answer 2

Sposób, w jaki obecnie to robię jest następujący (przepraszam długi wpis).

public function createAction($title, $content) { 
    try { 
     $post = $this->commandBus->execute(new CreatePostCommand($title, $content); 
    } 
    catch (Exception $e) { 
     return $this->render('some error template file', $e); 
    } 

    return $this->render('successful creation template file', $post); 
} 

ten sposób tworzysz post i jeśli wszystko pójdzie zgodnie z planem, zwróci obiekt $ post i wysłać to do widzenia. Z drugiej strony, gdy wyjątek jest zgłaszany podczas wykonywania, wychwytujesz ten błąd i wysyłasz go do widoku.

Mój preferowanym sposobem jest połączenie kontrolera metodę na usługi, która udaje, że zachowanie i mieć kontroler wstrzykiwany jako słuchacz, który zarządza odpowiedzi, a mianowicie:

public function createAction($title, $content) { 
    $service = new CreateActionService($title, $content); 

    return $service->create($this); 
} 

public function onError(Exception $e) { 
    return $this->render('some error template file', $e); 
} 

public function onSuccess($post) { 
    return $this->render('success', $post); 
} 

Następnie w swojej służbie. ..

public function create($listener) 
{ 
    try { 
     $this->commandBus->execute(new CreatePostCommand($title, $content); 
    } 
    catch (Exception $e) { 
     return $this->listener->onError($e); 
    } 

    return $this->listener->onSuccess($post); 
} 

ten sposób usługa jest zarządzanie różnymi wyniki handler komenda może powrócić, a kontroler pozostaje po prostu zarządzać odpowiedzi, które możesz wrócił do swojej warstwy prezentacji.