Question

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 !

Answer 1

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.