MVC Variations Confusing Me
I've read this in one article:
# a model consisting of the application with no externalinterface;
# a view consisting of one or more graphical frames that interact with the user and the application; and
# a controller consisting of the ``main'' program that constructs the model and the view and links them together.
Additionally,
When a program with a graphicalinterface starts, the controller
1. creates the model (application),
2. creates the view consisting of one or more graphical frames and attaches commands to the graphical input controls (buttons, text boxes, etc.) of the view,
3. activates the graphical components in the view, and
4. terminates.
Here's what I understand: anything that can be seen or has a graphical component is automatically a view. This includes Swing, AWT, even a JFrame with all the buttons and stuff in it. I've also read somewhere that Views can opt to register to a Model to automatically update itself when the Model changes, but that the Controller would handle the registration process. Models only store state, or data. They DO NOT have to do any special formatting or know how to present themselves. They don't know about any Views. Controllers contain the application-specific logic. They just tie the two together then terminate. They don't have a user interface. Hence, the following code...
class Model
{
// misc. code.
private String name;
publicvoid setName(String name)
{
this.name = name;
}
public String getName()
{
return name;
}
}
class Controller
{
// misc. code.
private Model model;
private View view;
public Controller()
{
model =new Model();
model.setName("I am Sam");
view =new View();
view.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
view.addOkButtonListener(new ActionListener()
{
publicvoid actionPerformed(ActionEvent e)
{
view.setNameTextFieldText(model.getName());
}
});
}
publicstaticvoid main(String[] args)
{
new Controller();
}
}
class Viewextends JFrame
{
// misc. code.
private JButton okButton;
private JTextField nameTextField;
publicvoid addOkButtonListener(ActionListener l)
{
okButton.addActionListener(l);
}
publicvoid removeOkButtonListener(ActionListener l)
{
okButton.removeActionListener(l);
}
publicvoid setNameTextFieldText(String text)
{
nameTextField.setText(text);
}
}
is an example of MVC, or at least that is my understanding of it. I was just beginning to appreciate the above pattern when all of a sudden, I encounter this(http://www.cs.tufts.edu/~jacob/106/lecture/25_MVC.html), again putting me in a state of confusion.
If I stick to the definition of a controller given earlier in this post, I would say that the second example's controller is...."wrong". The Controller class has a view of its own. Additionally, the Controller uses a common callback for handling button events. I've read in the same article that this is bad design. The author presents some reasons, but in short, a common callback could turn into one long MONSTER IF statement mayhem.
Since the focus of MVC is on improved object reuse, model and view objects should be loosely coupled. Controller objects get reused the least. In the second example, all Views have a Model object inside of them, lessening their reusability. If in the first example, the Controller object acts as the glue that magically binds the model and view objects together, in the second example, glue is all over the place.
In the first example, if one removes the Controller class, the Model and View objects remain intact. If the Model is removed, the Controller is surely affected but the View still remains intact. We can even change the Model's API, and all that would need to be changed is the Controller.
In the second example, if one removes the Model object, the Controller and View objects are compromised. If we completely change the Model's API, the Controller and View objects would need to be changed too.
The second example has gotten me so confused I feel I need to ask these questions:
1.) Why does the second example maintain a tight coupling between the Model and the View?
2.) Why does the Controller have it's own View?
3.) Does the second example have any strengths over the first example? Or does the first example have any weaknesses too? In short, what can the first example do that the other can't and vice versa?
3.) In what types of problems is one more suitable than the other?
4.) Which is better in the long run or in larger projects (in terms of modularity, ease of coding, maintainability, etc.)?
I really need to clear this up. :)
