Cosa dovrebbe esserci nel mio modello e cosa dovrebbe essere nel mio controler?

2

Stiamo scrivendo un sistema con una sorta di struttura quasi MVC (non è mai stato affermato in questo modo, ma è quello che è). Sto sviluppando una conoscenza completa del sistema e il controller dovrà effettuare chiamate per aggiornarlo; il sistema stesso è qualcosa di simile a un grafico.

Abbiamo bisogno di avere un senso di un percorso tra più nodi e un modo per identificare il nodo originale. Ricevo connessioni tra due nodi nella costruzione del mio grafico originale, quindi la conoscenza del percorso completo e del nodo di origine non viene letta direttamente ma, ovviamente, si può dedurre una volta che ho finito di costruire il grafico.

Il mio istinto era di scrivere un percorso di base che tracciava una sorta di logica nel mio modello. Ogni nuovo arco inferiremo il percorso esistente e qualsiasi nodo di input originale tracciando il percorso in avanti e all'indietro in modo appropriato. Tracciare il percorso in avanti o all'indietro richiede un po 'più di conoscenza di un sistema, la connessione tra i bordi e i nodi è un po' più complicata, quindi solo il bordo 1 collega il nodo da A a B.

La mia domanda è, farebbe ancora questo nel regno del modello? Se faccio tutto questo tracciato dei percorsi, determinando i nodi di input, identificando i percorsi, ecc. Sto facendo troppo lavoro che dovrei davvero archiviare nel controller per una modifica più semplice in seguito? Ho bisogno di avere alcune capacità di traccia per costruire il grafico originale prima che il controller sia inizializzato, ma naturalmente potrei avere il controller che fornisce metodi che chiamo per fare tracciamento del percorso e simili ad usare l'implementazione del controller quando si costruisce il grafico. Non penso la logica per il grafico stesso cambierà, solo il modo in cui lo usiamo per il tasking, e fare cose nel modello rende più facile perché il modello può modificare direttamente gli oggetti quasi immutabili mentre non sto permettendo al controller di farlo senza chiamate al modello (variabili del pacchetto scope).

    
posta dsollen 01.04.2013 - 18:36
fonte

2 risposte

3

Cerca di adattarlo il più possibile al modello. I controller sono solo per le azioni di business, che di solito sono solo variazioni di CRUD (creare, leggere, aggiornare, eliminare). I modelli servono per fare la logica avanzata. Ad esempio, il business richiede che io visualizzi il percorso da A a B. L'azione del controller per visualizzare un percorso direbbe al modello di trovare e tracciare il percorso per esso. Quindi il controller passerebbe i dati alla vista. I controller passano principalmente i dati avanti e indietro.

Ecco una buona analogia: link . È per CakePHP, ma dovrebbe essere vero per tutti gli MVC.

    
risposta data 01.04.2013 - 19:34
fonte
0

Il tuo modello contiene informazioni che la tua vista deve mostrare. Questo include:

  • Campi associati ai dati
  • Vari risultati
  • Testo generato

Nel tuo contesto, considera il modello da inserire con i dati che è necessario visualizzare dalla vista.

Per quanto riguarda il controller, un'azione in un controller effettua le seguenti operazioni:

  • Esegui qualsiasi convalida della voce
  • Esegui qualsiasi logica aziendale
  • Compila il modello
  • Restituisce la vista, popolata con il modello.

L'eccezione a quanto sopra è per le lingue che supportano le annotazioni in cui è possibile avere la convalida sui campi del modello.

My question is, would doing this still be within the realm of the model?

Potenzialmente. È probabile che sia una risposta del tipo di sondaggio, ma a mio parere è accettabile disporre di metodi all'interno di un modello che trasforma i dati già presenti nel modello. Dovrebbe essere puramente trasformativo e non avere conseguenze esterne.

    
risposta data 02.04.2013 - 00:34
fonte

Leggi altre domande sui tag