La struttura annidata con responsabilità di diffusione non è logica?

2

Dato il seguente snippet di codice in un controller di Laravel:

$this->userRepository->saveByProject(
    $this->fileRepository->saveByProject(
        $this->metricRepository->saveByProject(
            $this->projectRepository->saveByUser(
                $request->attributes->get('user'), $request->all(), $id
            ),
            $request->input('metrics')
        ),
        $request->input('files') ?? []
    ),
    $request->input('contact') ?? []
);

Come puoi vedere, ogni primo parametro dovrebbe essere un 'Progetto' (un oggetto che implementa l'interfaccia 'Progetto').

Punto dubbioso

Il punto dubbio è il metodo 'saveByProject' in ciascun repository. Ad esempio, in UserRepository, salva l'utente e la relazione tra utente e progetto dato e restituisce il progetto con l'utente correlato. Spero tu capisca la costruzione. Sai che funziona anche per i file (FileRepository), ecc.

Pro e contro della soluzione sopra

Pro:

  • Meno dipendenze in ProjectRepository
  • Meno procedurale, perché è una dichiarazione
  • Leggibile, ma diverso da "logico"

Contro:

  • Repository multipli con il metodo 'saveByProject'
  • Meno leggibile rispetto al concatenamento di metodi

Alternativa: metodo di concatenamento

Pro:

  • Più leggibile
  • FileRepository e altri repository non sanno nulla di Project

Contro:

  • ProjectRepository ha molte dipendenze (vedi lo snippet di codice sotto)
  • ProjectRepository ha molti metodi

Frammento di codice:

$this->projectRepository->saveProject(
    $request->attributes->get('user'), $request->all(), $id
)
->saveFiles($request->input('files')) // call FileRepository
->saveMetrics($request->input('metrics')); // call MetricRepository 

// etc.

Ogni metodo save * chiama il repository giusto, ma gestisce il salvataggio della relazione con il progetto da solo e restituisce il progetto.

    
posta schellingerht 19.07.2016 - 17:17
fonte

0 risposte