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. Also, keep in mind, that 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 see 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.
Source
: https://en.wikibooks.org/
Comments
Post a Comment