Riconciliazione MVC con un modello di strategia

2

Sto lavorando su un'applicazione Rails che utilizza un MVC classico come struttura fondamentale. In quella struttura il controllore dovrebbe essere responsabile di "quale vista visualizzare quando".

Ora, dopo aver letto un modello di progettazione, ho imparato a conoscere i modelli di progettazione e, ispirato, ho iniziato a cercare modi per utilizzarli per migliorare la qualità del codice. Un paio di mesi fa ho iniziato a scrivere codice che rende una collezione di libri (non proprio, sto solo semplificando qui). Ogni libro è un'istanza di classe ruby e ha una proprietà 'tipo'. A seconda della proprietà del tipo, i libri sembrano drasticamente diversi l'uno dall'altro (per i libri diversi vengono utilizzati interi confronti parziali). Ora ho avuto la possibilità di avere qualcosa come un if statement nel mio controller o vista, scegliere quale partial renderizzare per ogni libro, o associare direttamente un partial con la proprietà type del book (che è più simile a un pattern di strategia, penso ). Il secondo modo mi è sembrato molto migliore, perché mi sono liberato di tutte le affermazioni, quindi è quello per cui sono andato. Ho semplicemente fatto qualcosa come render books nella vista e ogni libro reso correttamente in base al tipo.

Tutto sembrava bello, comunque. Ora ho iniziato a pensare se questo è contro il modello di mvc. Il modo in cui il codice è scritto ora, il controller non sta decidendo nulla su come rendere un particolare libro. Confermando la mia paura di una potenziale stranezza, i designer con cui lavoro mi hanno portato alla mente che di solito guardano solo il livello delle viste delle rotaie (sono responsabili della scrittura della struttura html). Prima potevano facilmente seguire quale partial era stato reso per ogni libro, come prima che tutta la logica fosse nella vista in una forma di leggere facilmente if statements . Ora per scoprire quali rendering parziali per quale tipo di libro devono andare fino in fondo nel livello del modello. Sembra sbagliato averli andare lì.

Ho fatto la cosa sbagliata inserendo la logica "which partial to render" nel modello?

    
posta redFur 19.12.2018 - 14:19
fonte

3 risposte

4

Il pattern di progettazione MVC non specifica i meccanismi coinvolti nella scelta della vista da renderizzare. Entrambi i modi sono "MVC".

Se esegui il rendering di una raccolta di libri, il controller visualizza una singola vista responsabile del rendering di una raccolta di libri .

Se il controller esegue il rendering di un singolo libro, deve eseguire il rendering di una singola vista per un singolo libro .

Sono due visualizzazioni diverse.

Il vero problema da risolvere è dove deve vivere la logica di decidere quale vista rendere in base al tipo di libro. Se metti questa logica nel modello, allora è certamente portatile e riutilizzabile. Puoi metterlo in una vista anche. Penso che Principal of Least Astonishment fornisca la migliore guida qui.

Dove ti aspettavi di trovare questa logica da parte tua o dei tuoi compagni di squadra?

Mettilo lì e non preoccuparti tanto di "violare" il modello di progettazione MVC, perché in realtà non ti dice dove mettere questa logica. Il modello di progettazione MVC riguarda principalmente Separazione delle preoccupazioni . Se la logica per la gestione dell'interazione dell'utente è separata dalla logica di rendering della vista, che è separata dai dati e dalla logica aziendale, allora stai seguendo lo schema di progettazione MVC.

Oltre a ciò, architetti il tuo codice in modo da non ottenere un'emicrania ogni giorno prima di andare a casa e puoi isolare le modifiche nel tuo codice base, invece di essere costretto a apportare modifiche radicali per semplici lavori di refactoring.

    
risposta data 19.12.2018 - 14:56
fonte
1

Penso che tu abbia fatto un ottimo lavoro identificando che potresti liberarti delle affermazioni if usando il polimorfismo. Non importa se questo aderisce all'adattamento MVC di Rails o meno. Secondo Martin Fowler, lo schema MVC è di gran lunga il modello più errato. Uno dei problemi riscontrati dagli sviluppatori iOS in questi giorni è chiamato il problema di Massive View Controller. Il che significa che mettono tutto il codice possibile nel controller della vista. Sei sulla strada giusta per spostare il codice di presentazione in classi separate. Anche se il modello potrebbe non essere il posto giusto per metterlo. Probabilmente ti viene in mente una classe separata per questo. La pagina di Martin Fowlers sull'architettura della GUI ( link ) è probabilmente un ottimo sito da esplorare.

    
risposta data 19.12.2018 - 14:52
fonte
0

Sì, questo va contro la progettazione MVC, ma non commettere l'errore di forzare un paradigma. MVC era probabilmente un design decente quando le applicazioni venivano ancora installate principalmente esclusivamente sul computer client. Al giorno d'oggi, è un po 'sorpassato, e mentre ciò non vuol dire che non dovresti fare un esempio da questo, dovresti usarlo come un trampolino di lancio per forzare la tua applicazione e non il sacro graal delle architetture di programma.

Non sono un programmatore di Rails, ma a me capita di apprezzare il modo in cui affrontano il problema. Posiziona elegantemente la logica nella vista piuttosto che nel controller. È necessario prenotare il controller per circostanze in cui non sarebbe realmente appropriato per una vista particolare.

E mentre eliminare le istruzioni if non significa necessariamente che sia un miglioramento, probabilmente è lo stesso, in quanto elimina i possibili percorsi nel programma e lo semplifica nel processo.

    
risposta data 19.12.2018 - 14:33
fonte

Leggi altre domande sui tag