Controller-service-repository w Laravelu - ilość Service'ów

0

Cześć,

Jak wygląda sprawa z tworzeniem ilości service'ów? Czy każdy endpoint powinien mieć oddzielny Service (oddzielny plik / klase), czy wystarczy jedna klasa na jeden kontroler tylko z większą ilością metod?

Załączam przy okazji swój controller do codereview -> https://pastebin.com/Vc6eWnGf

Jakie jest wasze zdanie?
Z góry dziękuję za odpowiedzi :)

0

@Jacek Trębicki: Nie znam Laravela ale tak na pierwszy rzut oka:

  1. Pierwsza z brzegu akcja index() powinna nazywac sie getAll/showAll w zaleznosci od gustu.
  2. Pierwsza z brzegu akcja, (zmieniona na getAll()) powinna byc akcja PhotoController'a nie PhotoReportController'a. Pobierasz fotografie, a nie jakies raporty o fotografiach - tak przynajmniej wynika to z danych ktore przekazujesz do widoku.
  3. Podobnie z serwisem. PhotoService, a nie PhotoReportService, zwlaszcza ze masz do czynienia z podstawowym R z CRUD'a.
  4. Nie wstrzykujesz wszystkich serwisow do konstruktora kontrolera, tylko indywidualnie serwisy do odpowiednich akcji. Chyba, ze masz jeden serwis odpowiadajacy jednemu kontrolerowi, ktory posiada wszystkie metody odpowiadajace wszystkim akcjom kontrolera. Wtedy to ma sens, ale w praktyce wychodzi Ci kobylasta ilsoc kodu umieszczona w jednej klasie. Lepiej jest wiec miec zestaw PhotoGetAllService, PhotoAddService, etc niz jeden PhotoService.
  5. Twoj serwis powinien tylko i wylacznie zajmowac sie CRUD'em (get, getAll, add, edit, remove) period. Zadnej obroki danych itp itd na potrzeby widoku. W przypadku Twig'a zajmuja sie tym extensions, Blade pewnie tez ma cos tym stylu.

Z grubsza rzecz biorac pierwsza z brzegu akcje przerobilbym w ten sposob:

<?php

namespace App\Http\Controllers;

use App\Models\Services\PhotoService;
...

class PhotoController extends Controller
{
    public function getAll(PhotoService $photoService)
    {
        try {
            return response()->view('photo.get_all', [
                'photos' => $photoService->getAll(),
            ]);

        } catch (Exception $e) {
            $data = ['error' => $e->getMessage()];
        }

        return response()
            ->view('photo.get_all', $data)
            ->setStatusCode(500);
    }
    ...
}

Ponadto zastanawia mnie przestrzen nazw kontrolra. Ten element Http jest wlasciwy dla Laravela, czy Twoj wlasny pomysl?
Podbnie przestrzen nazw serwisu. Services pod Models tez wyglada dziwnie, ale mozliwe, ze tak to sie robi w Laravelu.

Pozostaje jeszcze chwytanie wyjatkow, ale pewnie czyms tam "glebiej" rzucasz wiec pewnie wiesz co robisz. Pamietaj jednak, ze o ile w developmencie mozesz sobie wywalic caly "trace" problemu na ekran, o tyle dla produkcji, zapisujesz go do logow, a na ekranie wyswietlasz ewentualnie jakis lakoniczny komunikat. W skrocie musisz cos z tym jeszcze zrobic. Zreszta Laravel ma z pewnoscia na to jakies eleganckie rozwiazanie.

0

Chyba niepotrzebnie robic dodatkowa robote uzywajac repozytoriów do takich prostych aplikacji

1 użytkowników online, w tym zalogowanych: 0, gości: 1