Utilizzo di entityManager / repository Classe / produzione di sessione direttamente nel controller

Question

Utilizzo di entityManager / repository Classe / produzione di sessione direttamente nel controller

Naviga le tue risposte

#1 da (2 voti)

0

Mi chiedo quale sia il tuo approccio sul seguente argomento:

diciamo che abbiamo una struttura MVC con entità, repository, controller e livello di servizio.

Il mio approccio all'utilizzo sopra era abbastanza chiaro per me:

controller usa i servizi
eseguono manipolazioni sui dati quando necessario,
utilizzano classi di repository per salvare e aggiornare i dati da db
controller ottiene l'output dei servizi (quando necessario) e lo spinge per visualizzare

Tuttavia, ieri mi sono imbattuto in una soluzione popolare in Symfony2 world, in cui

controller ha accesso a entityManager / sessionFactory
controller usa servizi per eseguire manipolazioni ai dati
controller utilizza entityManager / sessionFactory e gli archivi direttamente per eseguire letture, salvare e gestire le transazioni del database.

All'inizio non ero d'accordo con il secondo approccio, so che infrange alcuni principi di architettura pulita, ma ... è mostrato in un sacco di tutorial ufficiali sul sito Symfony2 . Quindi ho pensato che sarebbe stato meglio chiedere.

In altre parole: è giusto rendere il controllore direttamente responsabile del salvataggio e del recupero dei dati e della gestione delle transazioni? Quali sono alti e bassi?

design architecture design-patterns services

posta ex3v 19.11.2014 - 09:34

fonte

1 risposta

Leggi altre domande sui tag design architecture design-patterns services

Utilizzo di PHP o C ++ per dispositivi elettronici reali Che cose possibili per accedere alla webapp mvc [chiuso]

score 2 · Accepted Answer

C'è il rischio che il secondo approccio porti ad un Fat Controller, che è spesso considerato un antipattern. È effettivamente una violazione di "architettura pulita" (come da zio Bob Martin) poiché il controller non è solo un "meccanismo di consegna" ma si occupa anche di transazioni applicative / casi d'uso, orchestrando le chiamate verso i repository e i servizi e prendendo decisioni basate su stato attuale dell'applicazione.

Gli svantaggi sono relativi a leggibilità, inclinazione del bug, manutenibilità e testabilità poiché la logica dell'interfaccia utente è ora intrecciata con la logica applicativa. Può anche favorire la duplicazione del codice (al contrario, il codice di un servizio può essere riutilizzato da più controller) e se si sceglie di aggiungere un altro livello UI (ad esempio, mobile) alla propria architettura, i casi d'uso dovranno essere copiati lì. Lo stesso se si desidera aggiungere un'API HTTP senza UI.

Il vantaggio principale è la semplicità. Con una piccola applicazione CRUD in cui ogni richiesta HTTP genera gli stessi passaggi di base (load entity, update / delete / display it, [save entity]), non è necessariamente necessario questo livello di riferimento indiretto. La logica applicativa può anche essere scomposta in una classe di controller di base con metodi di template.