2

I have an Eclipse RCP application with a ViewPart that follows the Model-View-Controller (MVC) design. The model is a POJO holding the current data. The ViewPart is the view that listens to changes on the model and reloads the UI if necessary.

In my application logic I want to fetch new data into the model when a user selects an entry from a list. Since the data is fetched from a server, I am using the Eclipse Job framework to do it in another thread, to not block the UI.

Now, I am struggling to find the best place to create and start the background jobs. Do you have any recommendations regarding this? I see two possible ways:

  • In the controller. For this, the controller would also need to listen to changes in the model. Should the job notify the controller when the new data is fetched and the controller updates the model; or should I pass a reference to the model to the job which updates the model on its own?
  • In the model. I have seen references which say that data fetching should be part of the model. In this ways I can directly control in the model which conditions trigger a loading of new data. This could be regarded as kind of a "business logic". But then I have a dependency on Eclipse internals within the model and so it's not anymore a standalone entity (harder to test).

Edit: I know that MVC is rather loosely defined. Would the answer be different or any clearer if I use for example the Model-View-Presenter design? IMHO in MVP the presenter has slightly better defined responsibilities.

jhyot
  • 3,733
  • 1
  • 27
  • 44
  • Related questions that I found: [Who should handle threading in MVC?](http://stackoverflow.com/questions/11407865/who-should-handle-threading-in-mvc), [In client side MVC, who should handle client-server communication?](http://stackoverflow.com/questions/16907874/in-client-side-mvc-who-should-handle-client-server-communication) – jhyot Jan 22 '15 at 17:42

1 Answers1

2

I would say...

User selects list entry -> controller handles event -> controller starts a job, passing the model -> job updates model -> UI updates based on change in model (if necessary)

My reasoning...

The role of the controller is to handle UI events - the list entry selection. From there, you are fetching data from the server and injecting it into the model. In my opinion, this should be kept separate (i.e. external) from the model - you could change the networking library being used, for example, without affecting the data model.

colti
  • 393
  • 1
  • 15
  • Thanks for your answer. Could you provide arguments or reasons why you think it should be this way? That would make the answer more useful. – jhyot Jan 22 '15 at 16:48
  • @jhyot Done. Hope that is sufficient. – colti Jan 22 '15 at 17:04