Model–view–controller
The model-view-controller (MVC) pattern is an architectural pattern used primarily in creating Graphic User Interfaces (GUIs). The major premise of the pattern is based on modularity and it is to separate three different aspects of the GUI: the data (model), the visual representation of the data (view), and the interface between the view and the model (controller). The primary idea behind keeping these three components separate is so that each one is as independent of the others as possible, and changes made to one will not affect changes made to the others. In this way, for instance, the GUI can be updated with a new look or visual style without having to change the data model or the controller.
Newcomers will probably see this MVC pattern as wasteful, mainly because you are working with many extra objects at runtime, when it seems like one giant object will do. But the secret to the MVC pattern is not writing the code, but in maintaining it, and allowing people to modify the code without changing much else. Different developers have different strengths and weaknesses, so team building around MVC is easier. Imagine a View Team that is responsible for great views, a Model Team that knows a lot about data, and a Controller Team that sees the big picture of application flow, handing requests, working with the model, and selecting the most appropriate next view for that client.
One of the great advantages of the Model-View-Controller Pattern is the ability to reuse the application's logic (which is implemented in the model) when implementing a different view. A good example is found in web development, where a common task is to implement an external API inside of an existing piece of software. If the MVC pattern has cleanly been followed, this only requires modification to the controller, which can have the ability to render different types of views dependent on the content type requested by the user agent.
Model
Generally, the model is constructed first. The model has two jobs: it must both store a state and manage subscribers. The state does not need to be anything special; you simply need to define how you're going to store data, with setters and getters. However, anything which can change (any property) must have a list of listeners which it contacts whenever the value changes. The property listeners allow us to have multiple views on the same data, which are all live-updated when the state changes. The code for this can usually be defined in a superclass and inherited, so that you just write it in one place and then it applies consistently to every property. Nested states (for example, dynamically configured properties) may require some extra thinking about how you want to report the changes.
People sometimes use the word 'model' to refer to the 'data model' -- the architecture of the data structures in the application. A good MVC framework takes care of the model superclass and subscriptions for you, so that you can simply define your own data structure in that framework's model-language, and then immediately build the other components. In this end-user sense, defining the data model is equivalent to defining a model. However, if you are designing a framework, it is not MVC if it lacks property listeners.
View
Once you write a data model, the next easiest thing to write is usually a view. The view is the part of the application which subscribes to a model. Usually it presents it to a user alongside a user interface, or GUI. The GUI contains other components too, which are usually part of the controller and can be handled later.
You can also have view-controller components which have nothing to do with user interfaces. You can imagine, for example, an MVC circuit-board application where a model simply manages numbers (voltages and currents) throughout the circuit. A resistor, for example, then has a "view" of the voltages at each end, tightly coupled to a "controller" which updates the current going through that resistor. All of the components talking to each other through the model would then eventually perform the circuit's actions in real-time.
When you're writing a view, there are two things to think about: "what do I do when the state changes?" and "how do I display this to the user?" Your MVC framework usually provides editors for various properties in the model, like date selectors, text fields, sliding bars, and combo boxes. More complex properties often require more complex views and editors, like tree views. Your MVC framework will probably have already figured out how to connect these components to the model, and might even auto-generate appropriate components based on the type of a given property in the model.
Controller
The rest of the GUI -- the parts which do not update when the model changes -- are the responsibility of the controller. This includes navigating around the view, as well as what you do when someone tries to edit the data in the view. Strictly speaking, a view cannot be edited and is 'read-only' -- when you try to modify a field in the view, the controller needs to pick up the editing event, process it, and send it to the model; the model will then update the view if/when the value actually changes.
Different frameworks handle controllers in different ways. Some frameworks allow callback functions to be associated with editors, which get called when the value is changed. Other frameworks allow you to add listeners directly to the component, which can be notified when the value in the editor changes, when it is clicked on, or when it loses focus, etc. In many frameworks, the controller appears as a collection of methods and listeners built into both the data model and the view. For example, if you have a "password" property in the model which needs to be salted and hashed before being stored, this logic might appear in a setPassword function living in the data model. Similarly, when a framework generates a view, the widgets for the view are often not read-only but rather read-write, with listeners. The actual controllers provided by the MVC framework then "plug into" each of these interfaces, and pass data between them.
Validation
When possible, it is usually best to allow the model to do all the necessary validation of values, so that any changes to the allowed values, or changes simply to the validation process, only need to be made in one place. However, in some languages under certain circumstances, this may not be possible. For instance, if a numeric property is being edited with a text field, then the value of the property passed to the controller by the view will be text, not a number. In this case, the model could be made to have an additional method that takes text as the input value for this property, but more likely, the controller will do the initial parsing of the text to get the numeric value, and then pass it on to the model to do further validation (for instance, bounds checking). When either the controller or the model determines that a passed in value is invalid, the controller will need to tell the view that the value is invalid. In some cases, the view may then issue an error dialog or other notification, or it may simply revert the value in its editor to the older valid value.
In Java, we can implement a fat client GUI. In this case, we can use:
- JavaBeans to implement the model and,
- SWT or Java Swings to implement the view and the controller.
However, in Java EE, we can also implement a web application. In this case, we can use:
- EJB entity to implement the model,
- JSP to implement the view and,
- EJB session to implement the controller.
