2

I am having some troubles understanding and implementing the MVC pattern.

I have a singleton "model" class which contains all the datas of the application and extends Observable. When those data are modified, I want to update the views, and when one of the views receives some input from the user, I want to update the model. In between stands a Controller (implements Observer) which has an instance of both the view and the model.

I think that to do this, the views must have an instance of the controller. Whenever it receives an event from a button or any component, it calls the correct controller's method, which transmit the informations to the model. The model is updated and notifies the observer which in turn will update every components of all the views, even if they are not linked to the particular data which has been modified, since the Controller can't know what has been modified in the model. I am not sure this is a good design.

I looked a bit upon the PropertyChangeListener class, which seems to correct this issue but I am not so sure that I understand everything. Is there any preferred way to do this ?

Thanks in advance !

Improve this question
4
  • you may like to read over this: oracle.com/technetwork/articles/javase/mvc-136693.html Commented Oct 22, 2012 at 10:30
  • 1
    @PaulDinh : I had read this (this is what I meant by "looking a bit upon"). So is that the way it should be done ? And if yes, what are the Observer/Observable classes for ? Commented Oct 22, 2012 at 10:32
  • @rob I am not sure I understand what you are saying, but it seems possible to uses PropertyChangeListener through the PropertyChangeSupport, as shown in Paul Dinh link. But I am getting more and more confuse so I might be wrong. Commented Oct 22, 2012 at 10:36
  • @Nicolas Apparently I'm the one that confused things here, sorry. Nevermind my previous comment (I deleted it to avoid confusing others) Commented Oct 22, 2012 at 10:42

1 Answer 1

Reset to default
2

There are a few issues with what you're suggesting.

First of all, you're describing MVVM, not MVC.

The second problem is that the terms model and controller aren't suppose to describe singletons. They are merely terms to help you separate concerns by organizing your logic into classes with well-defined responsibilities.

The MVC structure is as follows:

The Model

This is your application logic/business rules. This basically means that if your application is about a phone book, then all logic and data structures that have to do with providing a phone book API is implemented here.

The View

This layer is completely separate from the model, in that it doesn't care about data structures or logic, but only on presenting simple values. Strings, integers, collections, you name it. But it doesn't care about the model's API, it only depends on the controller's.

The Controller

This is where things come together. The controller is the mediator. It speaks the language of the model, and that of the view, and it can make them work together. User requests are routed to the controller. For example, a request might want to list all numbers in the phone book. What happens is:

  1. The controller receives the request
  2. Asks the model for all numbers that exist in the phone book via the model's API
  3. [Optionally] converts the data into a data structure which the view is intended to display
  4. Passes the data to the view

One last remark before we finish:

If the controller doesn't convert data from the model into something simple, then allegedly the view is now tightly-coupled with the model. However, that doesn't always have to be the case. Even if the model's API changes, then the controller might still be able to adapt the new API into the old API, which the view already understands.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Thanks for the answer. I don't really get why having a singleton for model is an issue (but maybe you meant that it doesn't have to be a singleton). If I get what you say, it goes like this: the user changes a phone number, the controller gets the event and do whatever it must do, in this case update the phone number in the database using the model API. The model tells the controller it has been modified, which in turns create a new list of phone number and send it to the view. I think this is the correct MVC pattern. One question remains, how do the controller know what has been modified?
1. I was suggesting it better not be a singleton, just out of real-life experience. But it's not mandatory that it isn't. You can use it if you like. 2. The controller can subscribe to a Changed event on the model if it wishes, and if it exists. Otherwise, it needs to sample it every now and then, and compare with previous results.
this time I think I got it. So I could generate an event using the PropertyChangeSupport API, so that the controller(s) can know specifically which properties has been modified and act in consequence.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.