Reputation: 5555
Let's say I have a large collection of Image models and at any one time, only 50 thumbnail views are actually rendered. I want to give the user the option to see another 50 random images from the collection...so I thought of giving each Image model a onDisplay attribute.
The show-random method picks 50 random items and sets onDisplay to true. Some of these items may have already been rendered...if not, then a new thumbnail view is created and attached to the Image model. If the view was already rendered, then it is just redisplayed/attached to the DOM.
The checking of the view's existence seems most easily done if the model has a pointer to it. But am I violating separation of concerns here?
Upvotes: 3
Views: 239
Reputation: 9078
Yeah, I agree, you don't need to couple your model to their views like that.
The onDisplay attribute is good. If all of your Image models are in a collection, then just have another "parent" view listen to changes to the onDisplay attribute on the collection.
If the attribute changes, the "parent" view can then render/remove the thumbnail views (as they will be subviews) as required.
Upvotes: 1
Reputation: 47971
In the MVC design pattern the model should not know anything about the view. This, for example, lets the model to be viewed in more than one way, say either as HTML or rendered in a canvas element.
This can be seen in the following diagram:
The Model can update the View only indirectly, e.g. by firing events.
Image copied from here.
Upvotes: 8
Reputation: 98559
Why don't you make an outside method which handles the caching of views? When the model goes to build a new view, instead of directly constructing it, it would pass the parameters to that outside method.
From the model's perspective, it's calling a generic "give me a view" function. It's that function that handles the caching. You can then change that function to change the behavior, without having to directly modify the model.
Upvotes: 0