MVC - The right way
From: Tony Weston (aweston_at_connectfree.co.uk)
Date: 09/12/04
- Previous message: Fredrik Bertilsson: "Re: Distributed applications and OOD"
- Next in thread: Fredrik Bertilsson: "Re: MVC - The right way"
- Reply: Fredrik Bertilsson: "Re: MVC - The right way"
- Reply: Tony Weston: "Re: MVC - The right way"
- Reply: H. S. Lahman: "Re: MVC - The right way"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 11 Sep 2004 23:19:22 -0700
It seams that MVC Has become the de-facto way of producing GUI code.
However, in the last few years, I have come across a few
implementations that claim to be MVC, but in fact are not. So, this
post is about clearing the chaff from the wheat (so to speak)... and
dispelling the myths about what is/is not MVC.
According to the smalltalk model, MVC is the following.
VIEW
Retrieves data from model
Listens for data change notifications
Posts events to the controller
'Knows' about model + controller interface
CONTROLLER MODEL
Listens for events from View Holds 'State' of application
Maps data changes to Model provides information to View
knows about model interface Uses the observer pattern,
to notify others of data changes
knows neither View
or Controller interface.
So the theory goes like this;
1) When the View needs to display data, it requests this data from
the model.
2) The view registers itself as an observer to the model, so that
changes to the model can be shown.
3) When an event is evoked in the view, the view forwards this
event to the controller
4) When the model is updated, it notifies its observers of the
change.
In Java Swing, each component tries to follow the MVC Pattern. This is
OK, but when building a screen that contains many components, the
Swing MVC, and my application panel MVC are not the same, in any way.
Swing could be replaced with, say VB non-MVC components, and the panel
MVC would remain.
According to the above triad, the view requires a model to display
data. The model that is used, is dependent on what the data needs to
be shown by the view. If a customer name is needed, then a customer
model is required. If a part description is needed, then a part model
is required. If both are needed, then both models are required. As the
View is responsible for what data is to be shown, to comply with
encapsulation, it should be the view that contains code to either
instantiate the models, or to retrieve singleton models from somewhere
instead.
This is where the first myth about what MVC is comes in...
FALLACY 1: The data model in an MVC architecture, should be
designed to match the data in the view.
This is totally wrong, it implies that the model is, at least at some
level, logically coupled to the view. And therefore requires:
1) Each view has a single data model that solely serves the purpose
of providing data to that view
2) Any code maintenance changes to the fields shown in the view,
require the addition/removal of fields in data model to hold the data.
This holds true for those frameworks that 'automatically' create a
data-model based on the layout of the view, to 'assist' the coder. I
will put it to you, that there is no difference from populating a view
directly (bypassing MVC completely), than populating a view based
model and firing a data-changed event. apart from the latter code been
more complex, and difficult to maintain.
Conversely, a data model, should not simply be a list of private
fields with getters/setters (in effect, a 'C struct'). The data model,
should be, instead, a 'business entity' (a Part,or a Customer,or an
Order, etc), with nothing, whatsoever, at all to do with the view.
Indeed, data models can be reused many times throughout the system,
with many different views making use of them.
The data model, is what should contain the code that retrieves the
data from the server, and contains the code to update this data, if
needed, thereby shielding the View and Controller from any database or
business logic changes, which is the entire point of using MVC in the
first instance.
A customer model might contain methods getCustomerList(),
setCustomerName(), deleteCustomer() and so on. There could also be a
Customer object, that is passed/returned from the model, if needed,
and would contain that actual data of a single customer. The
CustomerModel is not the same as a Customer object!
FALLACY 2: In Client server apps, we have a business object, that
retrieves data from the server, and populates the model, using
getters/setters, and then fires a data changed event.
This, is again, wrong. Coupled with the first fallacy, it implies that
any view changes, will require not only changes to the data model, but
now will require changes to the business object to support the new
fields... I can not see any need for a business object, and the
concept of business objects were 'invented' as MVC wasn't fully
understood. If a new field is added to the database, then methods to
access this field are added to the model. This will not cause any
problems in the view. If , however, a no longer supported field is
removed from the database, by removing the accessor methods from the
model will hi-light all views (with compile errors) that contain
references to the accessor method, making it easy to determine which
views are to be re-factored.
By having the datamodel contain the database code, it also becomes
possible for Real-time updates, to be easily shown on the screen (just
add a trigger to the database, to execute a data-changed method in the
model)....
(rest of post, to be continued.....)
Cheers,
Tony
- Previous message: Fredrik Bertilsson: "Re: Distributed applications and OOD"
- Next in thread: Fredrik Bertilsson: "Re: MVC - The right way"
- Reply: Fredrik Bertilsson: "Re: MVC - The right way"
- Reply: Tony Weston: "Re: MVC - The right way"
- Reply: H. S. Lahman: "Re: MVC - The right way"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
