Where is the M in MVC ?
The question I am going to ask was inspired by my latest work with the Flex platform (and some frameworks pretending to implement MVC), but I think it's general enough to involve people with various expertise.

For quite a lot of time I have followed the paradigms, proposed by frameworks like Cairngorm - 

View, bound to properties of a singleton model, and dispatching events.
Events get caught by the front controller, and commands get executed as a result.
commands call services, get data, and supply the model.
The model implicitly updates the views through bindings.

It was all nice and sound until I got to the following data structure:

User
 has many followers (Users)
 follows many Users 
 has a bunch of photos
 follows many locations

Photo
 has many likers (User)
 has a location
 has a creator
 has many related photos

Location
 has many photos
 has many followers

Again, it would not be a problem to use the idea proposed by Cairngorm, for instance to have
a currentUser, currentLocation, and currentPhoto, and just bind to them. 

The problem comes in the views themselves. I have a series of complex "page" views, which provide as drilled information, as one could imagine. For instance, the location page, shows a grid of latest/popular photos, a panel for for followers, and a map of based on the coordinates where those photos were taken. Here come the problems:

Obviously, for performance reasons, I cannot fetch all users that are following a particular location, or all photos a location could have. I have pre-fetched some, and others will supplied by the server on demand.

I want to drill-down staying on the same view, for example when clicking on a follower's avatar page, i should get a small grid of that user's photos, or sth. But i only have one currentUser in the model.

This leads to the question, why do i even need to bind to a central singleton model? Can't I just turn every view into a sort-of responder, i.e the view dispatches an even again, but this time the command instead of supplying the model, will supply the calling view directly. 

There won't be any coupling because every view will implement IResponder. The command will require only an IResponder, which it will get from the Event it was called with.

The "model" as I see it, will play a different role. It will be more like a cache, a sort a global Dictionary for local storage, which will be checked by the command before it makes a request from the server. This way it may save some calls to the server, although, if the data is very sporadical, this same data will be fetched again and again together with other data. (I may have some user data in the cache, but in general I will call the server for a collection of follower data, regardless of whether some of it I might already have or not, for consistency )

Any feedback on these ideas will be appreciated
 
Where is the M in MVC ?
===

The question I am going to ask was inspired by my latest work with the Flex platform (and some frameworks pretending to implement MVC), but I think it's general enough to involve people with various expertise.

For quite a lot of time I have followed the paradigms, proposed by frameworks like Cairngorm - 

View, bound to properties of a singleton model, and dispatching events.
Events get caught by the front controller, and commands get executed as a result.
commands call services, get data, and supply the model.
The model implicitly updates the views through bindings.

It was all nice and sound until I got to the following data structure:

User
 has many followers (Users)
 follows many Users 
 has a bunch of photos
 follows many locations

Photo
 has many likers (User)
 has a location
 has a creator
 has many related photos

Location
 has many photos
 has many followers

Again, it would not be a problem to use the idea proposed by Cairngorm, for instance to have
a currentUser, currentLocation, and currentPhoto, and just bind to them. 

The problem comes in the views themselves. I have a series of complex "page" views, which provide as drilled information, as one could imagine. For instance, the location page, shows a grid of latest/popular photos, a panel for for followers, and a map of based on the coordinates where those photos were taken. Here come the problems:

Obviously, for performance reasons, I cannot fetch all users that are following a particular location, or all photos a location could have. I have pre-fetched some, and others will supplied by the server on demand.

I want to drill-down staying on the same view, for example when clicking on a follower's avatar page, i should get a small grid of that user's photos, or sth. But i only have one currentUser in the model.

This leads to the question, why do i even need to bind to a central singleton model? Can't I just turn every view into a sort-of responder, i.e the view dispatches an even again, but this time the command instead of supplying the model, will supply the calling view directly. 

There won't be any coupling because every view will implement IResponder. The command will require only an IResponder, which it will get from the Event it was called with.

The "model" as I see it, will play a different role. It will be more like a cache, a sort a global Dictionary for local storage, which will be checked by the command before it makes a request from the server. This way it may save some calls to the server, although, if the data is very sporadical, this same data will be fetched again and again together with other data. (I may have some user data in the cache, but in general I will call the server for a collection of follower data, regardless of whether some of it I might already have or not, for consistency )

Any feedback on these ideas will be appreciated
 