3

Is it ever really acceptable to reassign the model for a view in MVC? (Or MV* where applicable.) In other words, for a single view instance, is it ever ok to reassign the view's model? That is, as opposed to using setters (mutators) on the model so that it does not have to be reassigned. Under what conditions (if any) is this acceptable MVC design?

Here is an example in JavaScript, but the question is language-agnostic.

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();

In the line view.setModel(model2);, the model is reassigned (the approach in question). In the line model2.setMessage('hi again');, the model is instead mutated via its own setter, which in my view seems generally preferred.

One of the main drawbacks I can see to model reassignment is that it could complicate attempts to reuse the model elsewhere in the application. In some MVC applications a single shared model could be used to drive multiple views (e.g. list, editor, and display views of the same data), in which case model reassignment would be problematic -- it would at least require the added complexity of communicating the model reassignment to dependent views. Here I think the DRY principle trumps the no-mutators principle. (Open to argument here.) Can an even stronger case be made?

To recap, under what circumstances might model assignment be acceptable, if any? Perhaps in certain languages, under extreme performance constraints...? Is "do not reassign models" a good rule of thumb? A pointer to an authoritative source or real-world situation would be helpful.

1 Answer 1

2

Why do you even want to NOT reassign the model? In any case the controller should be the one who knows how to fit everything together - load a new instance from the backend, assign it to the view, tell the view to re-render (if not implicit), get the changes from the view and communicate them to the backend to persist them.

There are even developers out there who want to avoid mutators on domain objects at all, because it is much easier to handle unmodifiable instances in concurrent systems. Some even do that when changing properties via a GUI - when the user changes a value a new instance is created based on the previous one with the modified value. That is a bit extreme IMO, however they have a point.

According your example: in the last lines you modify model2 by using a getter. But what does it mean? For me this makes only sense based on user-input because you modify a specific property of a specific instance probably identifiable by a unique id. If you want to simply refresh the data from the backend, using setters makes no sense to me, because you would have the effort to check whether you are updating the correct oject, do error handling (what if current instance is not the one you want to load?), etc. By replacing the whole instance, you know there is only that one instance used - clean approach, easy to understand.

1
  • Thank you. I will update my question to address your clarification questions.
    – Will
    Commented Feb 5, 2014 at 14:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.