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).