Is it not ok to have all of that state you're talking about down in the service? In my experience any state you have in the controllers can be problematic in bigger apps. When I started out I used to proxy everything through the controller but I've found that you end up with a lot of duplication that doesn't ever seem to pay off.
When you're talking about the various auth states you might have - they could be changed by more than just this view. That state could also be exposed in different controllers / views in different ways. Sort of seems like the state that each of those would use is the same (that in the service) - so is it ok for the views to just reference that state in the service directly?
Interested in hearing where that falls down. I'm fairly new to developing rich interfaces and I've struggled to find completely deinitive information on how best to architect these patterns. Lots of examples out there bind the views to the services but that may be shortsighted.
When you're talking about the various auth states you might have - they could be changed by more than just this view. That state could also be exposed in different controllers / views in different ways. Sort of seems like the state that each of those would use is the same (that in the service) - so is it ok for the views to just reference that state in the service directly?
Interested in hearing where that falls down. I'm fairly new to developing rich interfaces and I've struggled to find completely deinitive information on how best to architect these patterns. Lots of examples out there bind the views to the services but that may be shortsighted.