Repository, gateway, modelli e domande di architettura

4

Sto lavorando con un progetto Laravel e sto cercando un modo per risolvere il problema di modelli gonfiati e riferimenti incrociati tra loro.

Ho iniziato a estrarre metodi di livello superiore in un repository ma questo non risolve il problema di un metodo che deve conoscere un altro metodo.

Ad esempio, un metodo di ricerca delle attività deve prima cercare una lumaca in un'altra tabella. Non credo che dovrei inserire questo codice in un modello o in un repository, ma mi piacerebbe un singolo metodo per ottenere questa ricerca.

/Models/Slug
/Models/Task
/Repositories/SlugRepository
/Repositories/TaskRepository

Ora ho iniziato a sperimentare con l'aggiunta di un livello gateway / servizio con metodi di livello superiore che possono accedere a entrambi i repository sottostanti per completare l'attività.

Il servizio delle attività dipende dai due repository precedenti.

/Service/Task
findBySlug()

Penso che funzionerà, ma non sono sicuro che ora dovrei lasciare che i controllori accedano direttamente al repository o forzare tutto attraverso il livello service / gateway.

O forse eliminare completamente i repository e lasciare che i servizi accedano direttamente ai modelli, (comunque, Laravel abstracts db access).

E in cima a tutto voglio mantenere questo il più semplice possibile!

Qualcuno può confermare questo metodo come una buona scelta o no o magari suggerire un'alternativa?

    
posta ArthurGuy 10.02.2016 - 03:45
fonte

2 risposte

1

Alla fine e per mantenere le cose semplici sono andato per un repository di task e un servizio di slug. La ricerca di slug richiede l'accesso a un altro modello, motivo per cui l'ho portato a un servizio piuttosto che a un repository.

Credo che questa impostazione abbia mantenuto la separazione corretta impedendo ai repository di conoscere qualsiasi cosa sugli altri modelli e ancora di estrarre la logica di ricerca in una posizione più gestibile.

    
risposta data 16.02.2016 - 20:58
fonte
-1

Il repositoy fa parte del livello del dominio. Il modo in cui raggiunge i suoi obiettivi è nel livello infrastrutturale. Ad esempio un metodo come Task getTask (ID SlugId) potrebbe essere perfettamente nel repository Task. Ora, l'implementazione del repository potrebbe utilizzare un TaskDAO e uno SlugDAO per funzionare.

    
risposta data 09.09.2017 - 13:13
fonte