Quando è possibile riassegnare il modello per una vista in MVC?

3

È mai veramente accettabile riassegnare il modello per una vista in MVC? (O MV * dove applicabile.) In altre parole, per una singola istanza di visualizzazione, è mai ok per riassegnare il modello della vista? Cioè, al contrario di usare setter (mutatori) sul modello in modo che non debba essere riassegnato. In quali condizioni (se ce ne sono) è questo design MVC accettabile?

Ecco un esempio in JavaScript, ma la domanda è indipendente dalla lingua.

var Model = function (m) {
    var message = m;
    return {
        getMessage: function () {
            return message;
        },

        setMessage: function (m) {
            message = m;
        }
    };
};

var View = function (m) {
    var model = m;
    return {
        render: function () {
            alert(model.getMessage());
        },

        setModel: function (m) {
            model = m; // hmm, is this okay?
        }
    };
};

var model1 = new Model('hello world');
var view = new View(model1);
var model2 = new Model('hi there');
view.render();
view.setModel(model2); // reassign model
view.render();
model2.setMessage('hi again'); // mutate model via setter
view.render();

Nella riga view.setModel(model2); , il modello viene riassegnato (l'approccio in questione). Nella riga model2.setMessage('hi again'); , il modello è invece mutato tramite il proprio setter, che a mio avviso sembra generalmente preferito.

Uno dei principali svantaggi che posso vedere per modellare la riassegnazione è che potrebbe complicare i tentativi di riutilizzare il modello altrove nell'applicazione. In alcune applicazioni MVC può essere utilizzato un singolo modello condiviso per pilotare più viste (ad esempio lista, editor e visualizzazioni di visualizzazione degli stessi dati), nel qual caso la riassegnazione del modello sarebbe problematica - richiederebbe almeno la complessità aggiuntiva della comunicazione la riassegnazione del modello alle viste dipendenti. Qui penso che il principio ASCIUGGIA superi il principio dei non mutatori. (Apri argomento qui.) Si può fare un caso ancora più strong?

Per ricapitolare, in quali circostanze l'assegnazione del modello potrebbe essere accettabile, se del caso? Forse in alcune lingue, sotto vincoli di prestazioni estreme ...? "non riassegnare i modelli" è una buona regola generale? Un puntatore a una fonte autorevole o situazione reale sarebbe utile.

    
posta Will 30.12.2013 - 18:58
fonte

1 risposta

2

Perché vuoi anche NON riassegnare il modello? In ogni caso il controller dovrebbe essere quello che sa come montare tutto insieme - caricare una nuova istanza dal back-end, assegnarlo alla vista, dire alla vista di ri-renderlo (se non implicito), ottenere le modifiche dalla vista e li comunichi al backend per persisterli.

Ci sono persino sviluppatori là fuori che vogliono evitare i mutatori sugli oggetti di dominio, perché è molto più facile gestire istanze non modificabili nei sistemi concorrenti. Alcuni lo fanno anche quando cambiano le proprietà tramite una GUI - quando l'utente cambia un valore viene creata una nuova istanza basata sulla precedente con il valore modificato. Questo è un IMO un po 'estremo, tuttavia hanno un punto.

Secondo il tuo esempio: nelle ultime righe si modifica model2 usando un getter. Ma cosa significa? Per me questo ha senso solo in base all'input dell'utente perché si modifica una proprietà specifica di un'istanza specifica probabilmente identificabile da un ID univoco. Se si desidera semplicemente aggiornare i dati dal back-end, l'uso dei setter non ha senso per me, perché si dovrebbe verificare se si sta aggiornando l'oject corretto, si esegue la gestione degli errori (cosa succede se l'istanza corrente non è quella che si desidera caricare?), ecc. Sostituendo l'intera istanza, sai che c'è solo quell'istanza usata: approccio pulito, facile da capire.

    
risposta data 01.01.2014 - 14:45
fonte

Leggi altre domande sui tag