È una cattiva pratica avere molti modelli di visualizzazioni e controller?

Question

È una cattiva pratica avere molti modelli di visualizzazioni e controller?

#1 da (4 voti)
#2 da (-1 voti)

1

Sto progettando un sistema al momento usando MVC (con Laravel, se questo è importante) e sto cercando di decidere il modo migliore per architettarne una parte.

Un'analogia, puoi guardarla in questo modo:

Esistono post di blog e ogni post di blog può avere tre diversi tipi di commenti. Ogni tipo di commento è completamente diverso dall'altro e viene visualizzato su una pagina separata.

Quindi per esempio, supponiamo che un tipo di commento sia plain text . Ci sarebbe una pagina di testo in cui tutti i commenti in testo semplice per quel blog potrebbero essere visualizzati, modificati, creati, ecc.

C'è un altro tipo di tipo di commento chiamato Twitter . Ci sarebbe una pagina separata in cui tutti i Tweet pubblicati su quel post potrebbero essere visualizzati, modificati, creati, ecc.

E così via.

Il mio primo istinto era quello di provare e registrare tutti questi diversi tipi di commenti in un CommentController con un modello di commento, quindi leggere il CommentType e elaborarli in modo appropriato, salvandoli nella tabella corrispondente per quel CommentType, mostrando il giusto modulo per quel CommentType, ecc.

Ma sarebbe meglio avere un CommentController e modello diverso per ogni tipo? Cioè PlainTextCommentController / PlainTextComment Model e TwitterCommentController / TwitterComment Model?

Una parte di me ritiene che sia una cattiva pratica, perché sembra così inefficiente, ma non posso negare che migliorerebbe la leggibilità del codice.

Forse non ha bisogno di essere ottimizzato per usare intelligentemente un Controller, cercando di dargli la responsabilità per ogni tipo di commento. Forse sarebbe meglio dividere tutto, in modo pulito e chiaro?

Non sarebbe una cattiva pratica farlo?

architecture mvc laravel

posta Django Reinhardt 21.06.2017 - 16:31

fonte

2 risposte

Leggi altre domande sui tag architecture mvc laravel

La complessità artificiale è comune a chi è la società o la comunità? Aiuta con l'algoritmo per trovare il percorso ottimale tra i vari percorsi, dove l'ordine conta

score 4 · Answer 1

Non vorrei criticarti per avere tre controller diversi; non c'è assolutamente nulla di sbagliato in questo.

Tuttavia, se senti bisogno di inserire ogni tipo di commento nel proprio controller, ci sono buone probabilità che i tuoi controller stiano facendo troppo lavoro !

Ogni azione in un controller dovrebbe essere solo di poche righe, basta collegare le cose e dirigere il flusso dell'applicazione. Le azioni del controllore non dovrebbero comportare alcun sollevamento pesante, ma piuttosto sono responsabili della delega.

Ogni tipo di commento dovrebbe avere una propria classe di dominio di commento, funzionalità / proprietà condivise espresse con solo interfacce.

Ogni classe di commenti dovrebbe avere anche una propria classe di repository separata che è responsabile del salvataggio / lettura dal DB.

Ogni tipo di commento dovrebbe avere il proprio modello di vista e vista.

Dopo aver effettuato il refactoring di tutte le logiche di business e della logica DB dai controller, indipendentemente dal fatto che i tre tipi di commenti condividano o meno un controller, dovrebbe essere un punto controverso.

score -1 · Answer 2

All'interno del pattern di progettazione MVC (e degli altri pattern MV * correlati), c'è sempre un one (dominio) Model, sebbene ci siano molti ViewModels se li hai.

Il modello di dominio contiene tutto la logica dell'applicazione che non fa parte dell'interfaccia utente e può essere composta da tutte le classi necessarie per modellare il comportamento dell'applicazione.

Dovrebbe esserci una vista per ogni schermo e / o porzione riutilizzabile di uno schermo.

Infine, i controllori legano insieme il modello di dominio e le viste.

Con questo in mente, le classi Controllers e Domain Model non hanno controparti corrispondenti, se non per caso o in un design molto semplificato. È molto più logico se c'è una corrispondenza tra i controller e le viste, o i controller e le interazioni che possono essere fatte.

Nelle semplici applicazioni CRUD, senza logica applicativa più complessa della memorizzazione, rigurgitano ciò che l'utente ha inserito, l'ultima correlazione tra i controller e le interazioni può rapidamente assumere l'aspetto di una corrispondenza tra le classi Controllers e Model, ma non deve essere interpretata come ad esempio.

Per determinare quanti controller hai bisogno per i vari tipi di Comment , devi prima creare il tuo modello di dominio senza considerare quale sia l'interfaccia utente. Dopodiché, puoi pensare a quale tipo di interazione l'utente avrebbe con ogni tipo di Comment e se sono tutti abbastanza simili da gestire in un Controller o che dovrebbero avere Controller diversi. Una considerazione qui è anche se un singolo controller sarebbe in grado di eseguire attività comuni su Comment istanze senza sapere quale tipo di Comment con cui sta effettivamente interagendo.