I'm writing a rich client using eclipse rcp. I'm finding that I have various views that share state, in particular selection. An example of this for eclipse users is the outline and editor views, both observing a java class. Selecting methods in the outline view, causes the selection in the editor view to jump to that method and navigating in the editor view also causes the selection in the outline view to change.
In my example I have one view that displays a list of Markets. I also have another view that has a combo box. Changing the selection in the combo, updates the selection in the list and vice versa.
To implement this I added a bound selectedMarket property to the MarketService. All works great, although it doesn't sit perfectly with me - it doesn't seem like a typical resposibilty of a service layer object.
Do you think this sort of app state belongs in the service layer? It's quite handy in a way, in that the app state and the service are related. Deleting the selected market, obviously makes it no longer selected. Trivial when in the same service but if I seperated out the state into a seperate object I would have to add some extra binding to take care of this.
hmmm...well I think maybe I've answered my question, keeping this state in the service layer is easier which is a good thing. What do you think?