then found a note that the reason it was draft
was a concern that the body was still too buggy;
nevertheless, the first part is still interesting .]
7.17: web.adda/architecture/MVC vs MVVM:
8.31: summary:
. in trying to find an explanation of
the essential differences between
all the variants of the MVC architecture,
it was most helpful to see Alexy Shelest's
2009`MVC vs MVP and MVVM:
first he reminds us of MVC's original definition:
"( the “Gang of Four” book
doesn't refer to MVC as a design pattern
but as a “set of classes to build a user interface”
that uses design patterns such as
Observer, Strategy, and Composite.
It also uses Factory Method and Decorator,
but the main MVC relationship is defined by
the Observer and Strategy patterns. ).
[8.31:
. then, Shelest had an interesting summary of
the historical evolution of MV-architectures, eg:
"( Potel questioned the need for the MVC's Controller;. after reading that, I wrote this:
He noticed that modern user interfaces
already provide most of the Controller functionality
within the View class,
and therefore the Controller seems a bit redundant.).
. I didn't get mvc either, and promptly redefined it:here's gof's full explanation, paraphrased:
subrograms should not be controlling a gui interface,
rather they should be designed primarily for
use by other subprograms,
just as unix tools are meant to be .
(well, unix takes a shortcuts by
making its tool language a character string
that could also be readable by humans
but that was a security blunder because of parsing errors
that confuse critical datatypes like
{filenames, command names}).
. so, anyway, back to how humans fit in:
in order for a human to interact with
a subprogram that speaks type-tagged binary,
the human needs an agent who will
convert this robot speak into a gui .
. this agent is the Controller of the Model subprogram,
and it creates a View the human can interact with .]
The Model/View/Controller (MVC) triad of classes. see also wiki's overview of mvc and mvvm:
is used to build user interfaces in Smalltalk-80.
Looking at the design patterns inside MVC
should help you see what we mean
by the term “pattern.”
MVC consists of three kinds of objects.
The Model is the application object,
the View is its screen presentation
{bar graph, matrix of numbers, etc};
and,
the Controller is a strategy object:
it determines the algorithms used for
{key mappings, menu layouts, etc}.
(that's the Strategy design pattern;
and, there's the Factory Method pattern
specifying a view's default controller class).
MVC decouples views and models
by establishing a subscribe/notify protocol
-- that's the Observer design pattern:
Whenever the model’s data changes,
the model notifies views that depend on it;
and, each view can then update itself.
. the Observer pattern is decoupling objects
so that changes to a notifier
can affect any number of observers
without requiring the notifier
to know details of the observers .
MVC views can be nested,
thereby creating widget compositions .
-- that's the Composite design pattern:
whenever we want to treat a group
like an individual object,
subclassing makes composite widgets
usable everywhere that widgets are,
because they share the same supertype .
. one such composition is the scrollbar
done with the Decorator pattern
(the content and scrollbar widgets
are components of the scrollable widget,
where the scrollbar can be added optionally, dynamically;
ie, content widget can be decorated with scrollbar).
Josh Smith`Model-View-ViewModel
Windows Presentation Foundation (WPF)Martin Fowler 2004's Presentation Model (PM):
makes it easy to build UIs using
simple, time-tested, design patterns.
. the WPF community has been developing
its own ecosystem of patterns and practices
for designing and implementing
client applications with WPF;
and, this article reviews some of them .
. using the MVVM architecture
it's easy to test the functionality of a gui
when it exists in a set of ViewModel classes.
. why else should we use a pattern like MVVM?
let's review The Evolution of Model-View-ViewModel:
. the M-V-Presenter has enjoyed popularity;
MVP is a variation of the old mvc pattern .
What you see on the screen is the View,
the data it displays is the model,
and the Presenter hooks the two together.
The view relies on a Presenter to
populate it with model data, react to user input,
provide input validation
(perhaps by delegating to the model),
and other such tasks.
....
see Jean-Paul Boodhoo's August 2006 Design Patterns column. Fowler's Presentation Model,
was introduced as a means of creating a UI
with a platform-independent abstraction of a View .
. Presentation Model (aka Application Model) .
[ . "(presentation) = "(application) because
an application is known by its
presentation of a domain object
(aka the "(model) in model-view-controller;
because, the domain object is
modelling the domain process ).
. the presentation object is modeling
the view that is being presented to the user .
(by modelling we mean it's an abstraction,
so that our app need not deal with
the details of the view's concrete interface
(some widget toolkit, eg: tk, qt, gtk+, cocoa)]
The Presentation Model coordinates with the domain layer[. we're done with Martin Fowler's Presentation Model,
and provides an interface to the view
that minimizes decision making in the view.
The view either stores all its state
in the Presentation Model
or synchonizes its state with
Presentation Model frequently .
. several views can utilize the same Presentation Model .
In the case of composition
a Presentation Model may contain one or many
child Presentation Model instances,
but each child control will also have
only one Presentation Model (PM).
. the PM provides a separation of concerns
which may make it easier to
develop the user interface,
allowing you to test without the UI,
or to provide support for multiple views .
Compared to Passive View and Supervising Controller,
Presentation Model allows you to write logic that is
completely independent of the views used for display.
You also do not need to rely on the view to store state.
The downside is that
you need a synchronization mechanism
between the presentation model and the view.
Separated Presentation requires
much less synchronization
and Passive View doesn't need any at all.
How it Works:
The essence of a Presentation Model,
being an abstraction of the view,
is to be a class that represents
all the data and behavior of the UI window,
but without any of the UI-rendering controls
(that's the one thing the view does).
which class contains the synchronization code?
. If you put it in the view,
it won't get picked up by tests on the Presentation Model.
If you put it in the Presentation Model
you add a dependency to the view in the Presentation Model
which means more coupling and stubbing.
which way is the binding?:
. should the View reference the Presentation Model
or vice versa?
A Presentation Model that references a view
generally maintains the syncronization code
in the Presentation Model.
The resulting view is very dumb,
and contains only setters for any state that is dynamic
and raises events in response to user actions.
The views implement interfaces allowing for
easy stubbing when testing the Presentation Model.
The Presentation Model will observe the view
and respond to events by changing any appropriate state
and reloading the entire view.
As a result the syncronization code can be easily tested
without needing the actual UI class.
A Presentation Model that is referenced by a view
generally lets the view hold the syncronication code .
. although faults do occur in synchronization code,
they are usually easy to spot and fix
(unless you use fine-grained synchronization) .
and back to Josh Smith's article .]
John Gossman was a WPF and Silverlight ArchitectJohnGossman 8 Oct 2005`
[his last blog was 2009.01(silverlight is obsolete by then)]--
John Gossman 2005's blog unveiled the
Model-View-ViewModel (MVVM) pattern .
MVVM is identical to Fowler's Presentation Model,
in that both patterns feature an abstraction of a View,
which contains a View's state and behavior.
Fowler introduced Presentation Model as a
means of
creating a UI platform-independent abstraction of a View,
whereas, Gossman introduced MVVM as a
standardized way to leverage core features of WPF
to simplify the creation of user interfaces.
In that sense,
I consider MVVM to be a specialization
of the more general PM pattern,
tailor-made for the WPF and Silverlight platforms.
Model-View-ViewModel pattern for building WPF apps:
. Model/View/ViewModel is a variation of MVC[. we're done with JohnGossman's
that is tailored for modern UI development platforms
where the View is the responsibility of a designer
rather than a classic developer.
The designer is generally a artistic person,
rather than a C-coding computer programmer .
The design is almost always done in a
declarative form like HTML or XAML*,
and very often using a WYSIWYG tool
such as Dreamweaver, Flash or Sparkle.
. the business logic or data backend, by contrast,
is being developed by [ the C coders ].
. Model/View/ViewModel is thus a refinement of MVC
that evolves it from its Smalltalk origins
where the entire application was built using
one environment and language,
into the very familiar modern environment
of Web and now Avalon* development.
*: Avalon is the code-name for
Windows Presentation Foundation (WPF);
XAML( Extensible Application Markup Language;
formerly Extensible Avalon Markup Language)
forms a user interface markup language
to define UI elements, data binding, eventing, etc .
available under Microsoft's
Open Specification Promise.
The Model in MV-ViewModel,
is defined as it is in MVC: it is the
UI-independent modeller of the problem domain.
The View in MV-ViewModel consists of
the visual elements, the buttons, windows, graphics
and more complex controls of a GUI:
it does much of what the controller did in 1979's MVC,
encoding the keyboard shortcuts;
and, the controls themselves
manage the interaction with the input devices .
. The View is almost always defined declaratively,
very often with a tool [such as a XAML editor;
. that's what XAML is:
a way to declare with scripting
what your gui's look and feel will be .]
. some view states are not easy to represent;
eg, the UI may have multiple modes of interaction
such as "view mode" and "edit mode"
but these modes can't always be expressed in XAML
(though triggers are a great start).
We will solve this problem later.
At this point data binding comes into play.
In simple examples, the View can be
data bound directly to the Model.
In practice however, The Model is
very likely to have a data types that
cannot be mapped directly to controls.
The UI may want to perform complex operations
that must be implemented in code which
doesn't make sense in our strict definition of the View
but are too specific to be included in the Model
(or didn't come with the pre-existing model).
Finally we need a place to put view state
such as selection or modes.
The ViewModel is responsible for these tasks.
The term means "Model of a View",
and can be thought of as abstraction of the view,
but it also provides a specialization of the Model
that the View can use for data-binding.
In this latter role the ViewModel contains data-transformers
that convert Model types into View types,
and it contains Commands
that the View can use to interact with the Model.
a simple example of MVVM is the Library Panel:
The Model is a list of .NET assemblies
and associated with each list of assemblies
is a list of controls.
The View expose the assembly list in a ComboBox
and the list of controls in a ListBox.
We data bind the caption of the ComboBox
directly to the name of the Assembly
and the items of the listbox
take their text from the name of the Control.
The ViewModel has as state
the currently selected Assembly
and exposes Commands for
inserting a control into the scene.
Selection is one of the most common components
of a ViewModel.
But since controls have selection,
you may wonder why selection isn't left in the View instead.
This is done because often many controls in the view
need to coordinate based on a single selection.
It is easier in the ViewModel
to bind to a single representation of selection
than coordinate all the different controls in the view;
eg, in the Library, the selected Assembly
determines what is selected by the ComboBox
and also what list data is displayed by the ListBox.
Additionally, this arrangement allows us to change view
without copying over selection coordination logic
from their original view.
. the View could easily be changed,
and the ViewModel provides an abstract representation
for the reusable parts of this UI.
Model-View-ViewModel pattern for building WPF apps;
and back to Josh Smith's article .]
In Glenn Block's excellent September 2008 article-- [. the author once blogged at CodeBetter.com:
"Prism: Patterns for Building Composite Applications with WPF"
he explains the Microsoft Composite Application Guidance for WPF.
The term ViewModel is never used.
Instead, the term Presentation Model
is used to describe the abstraction of a view.
a community whose day jobs is Microsoft technologies,
particularly .Net based languages, Sql Server,
Sharepoint, BizTalk, server platforms and other software.]
Glenn Block`Patterns For Building Composite Applications
The Problem: Monolithic Apps[. we're done with Glenn Block's
Let's consider an example to understand the need for
composite applications.
... In this case,
the application is tightly coupled to each of the controls.
There is a significant amount of logic in the UI
for coordinating the different pieces.
There are also interdependencies among the controls.
Due to these dependencies, there's no easy way to
break up the application into a form where you can
develop each of the different pieces separately.
. As the system requirements change,
these dependencies impede evolution;
and, when modules can't be changed independently,
testing is much more costly .
You could put all the user controls in a separate assembly
to improve maintainability,
but that only moves the problem from the main app
to the control assembly.
It's very difficult in this [monolithic architecture] to
make significant changes or introduce new functionality.
Now let's complicate matters by
adding [the competitiveness requirements]:
we are working under a time-to-market constraint:
hence, these features must be developed
in parallel by different teams.
Each team develops separate controls:
To add both controls to the same control assembly,
they must each be added to the control project.
More important, they must be added to the main form,
which means that changes to both the
code and the XAML from each control
must be merged with the main form.
[. this development process is ] brittle,
especially for existing applications.
How do you [merge] all these changes
back into the main application?
. a lot of time has be spent doing
merges and diffs in source control;
and, if you make any mistakes,
you'll be left with a broken application.
rethinking the design: Composite Apps
A composite app consists of loosely coupled modules
that are dynamically discovered
and composed at run time.
Modules contain both view and model components
representing the different vertical slices of the system .
[. by contrast, horizontal slices of the system
would have all gui views in one module,
and all domain models in another module .]
The [gui] views are composed in a common shell
that acts as the host for all of the app's content.
Composites provide services that
tie these module-level components together.
Modules can offer additional services that
relate to the specific functionality of the app.
Modules never directly reference each other,
nor do they directly reference the shell.
Instead, they communicate via services .
[. by service he means the typical oop pattern,
where, rather than access other parts directly,
each module provides a set of functions
that another module can call for requesting services
such as accessing or communicating a state .]
At a high level,
a composite application is an implementation of the
Composite design pattern,
which describes a recursive UI structure of views
containing children that are themselves views.
The views are then composed dynamically
[to fit the dynamics of inputted data structures .]
If [the gui were ] built statically,
then this would require additional conditional logic
for [casing the inputted datastructures
as a prerequisite to building the view ].
. adding this additional logic will be
increasing the likelihood that existing logic breaks .
Separated Presentation
. established presentation patterns
you can apply within your views
to implement a composite pattern .
Throughout the Composite Application Guidance for WPF,*
you will see two recurring patterns that are used in the UI:
Presentation Model
and Supervising Controller.
*: Composite Application Guidance for WPF:
Prism was the code name for the guidance formally known asThe Presentation Model pattern
the Composite Application Guidance for WPF and Silverlight.
For brevity and conciseness, and due to customer demand,
this guidance is now referred to simply as Prism.
[provides an abstraction of the gui view .]
The rich support in WPF for
data binding, templates, and commands
makes the Presentation Model pattern
an attractive option for development.
Within the Supervising Controller pattern
there exists the model, the view, and the presenter;
The model is the data;
it is more often than not a business object.
The view is a [gui widget]
to which the model directly binds.
And lastly, the presenter is a class that
contains the UI logic.
In this pattern, the view contains very little logic
other than delegating to the presenter
and responding to callbacks from the presenter
to perform simple actions
including either displaying or hiding a control.
One of the challenges that arise when
implementing separated presentation
is the communication between the view
and the presentation model or presenter.
There are several approaches to handling this.
One that is often implemented is
having event handlers in the view
that either directly call or raise events to
the presentation model or presenter.
The same [gui widgets] that
initiate calls to the presenter
often have to be enabled or disabled in the UI
based on state changes or permissions.
This requires the view to have methods
that can be used to call it back
in order to disable those elements.
Another approach is to use WPF commands.
Out of the box, WPF provides RoutedUICommands.
RoutedUICommands are just
one implementation of commands.
WPF provides the ICommand interface
and will bind to any command that implements it.
This means you can create
custom commands to suit all your needs,
and you don't need to touch the codebehind.
The downside is that you have to implement
custom commands all over the place, such as
SaveCommand, SubmitCommand, and CancelCommand,
Prism to the rescue with CAL
(Composite Application Library):
The CAL provides the services
and plumbing for building composite apps.
It uses a composition model that allows
each of its services to be used piecemeal
or together as part of a CAL-designed app.
Each service is also easily replaceable
without recompilation of the CAL.
For example,
the CAL ships with an extension
that uses the Unity Application Block
for dependency injection
but lets you replace this with your own
dependency injection service.
The CAL ... allows you to wire up views
without having to delegate through
methods defined in the view itself
and without having to create
custom commands for each action.
In addition to routing commands between the view
and a presenter or presentation model,
there are other types of communication,
such as event publication,
that need to be handled in a composite.
In these cases, the publisher is
completely decoupled from the subscriber.
For example,
a module may expose a Web service endpoint
that receives notifications from the server.
Once that notification is received,
it needs to fire an event to which
components within the same or other modules
can subscribe.
Patterns For Building Composite Applications
and back to Josh Smith's article .]
Glenn Block's article explainedAlexy Shelest 2009`MVC vs MVP and MVVM:
Composite Application Guidance .
The term ViewModel is never used.
Instead, the term Presentation Model
is used to describe the abstraction of a view.
Throughout this article, however,
I'll refer to the pattern as MVVM
and the abstraction of a view as a ViewModel.
I find this terminology is much more prevelant
in the WPF communities.
Unlike the Presenter in MVP,
that needs a reference to a view,
MVVM's view binds to properties on a ViewModel,
and then the ViewModel, in turn,
exposes data contained in model objects
and other state specific to the view.
If property values in the ViewModel change,
those new values automatically propagate to the view
via data binding.
The bindings between view and ViewModel
are simple to construct because
a ViewModel object is set as the DataContext* of a view.
*: The DataContext
is the source of all entities mapped over a database connection.
It tracks changes that you made to all retrieved entities
and maintains an "identity cache" that guarantees that
entities retrieved more than one time
are represented by using the same object instance.
In general, a DataContext instance is designed to
last for one "unit of work"
however your application defines that term.
A DataContext is lightweight and is not expensive to create.
A typical LINQ to SQL application
creates DataContext instances
at method scope or as a member of short-lived classes
that represent a logical set of related database operations.
When the user clicks a button in the View,
a command on the ViewModel executes
to perform the requested action.
The ViewModel, never the View,
performs all modifications made to the model data.
The view classes have no idea that the model classes exist,
while the ViewModel and model are unaware of the view.
In fact,
the model is completely oblivious to the fact that
the ViewModel and view exist.
This is a very loosely coupled design,
which pays dividends in many ways, as you will soon see.
Why WPF Developers Love MVVM
Once a you become comfortable with WPF and MVVM,
it can be difficult to differentiate the two.
MVVM is the lingua franca of WPF developers
because it is well suited to the WPF platform,
and WPF was designed to facilitate
the MVVM pattern (amongst others).
The single most important aspect of WPF
that makes MVVM a great pattern to use
is the data binding infrastructure.
By binding properties of a view to a ViewModel,
you get loose coupling between the two
and entirely remove the need for
writing code in a ViewModel that directly updates a view.
The data binding system also supports input validation,
which provides a standardized way of
transmitting validation errors to a view.
Two other features of WPF
that make this pattern so usable
are data templates and the resource system.
Data templates apply Views to ViewModel objects
shown in the user interface.
You can declare templates in XAML
and let the resource system automatically
locate and apply those templates for you at run time.
You can learn more about binding and data templates in my
July 2008 article, "Data and WPF:
Customize Data Display with Data Binding and WPF."
If it were not for the support for commands in WPF,
the MVVM pattern would be much less powerful.
this article will show you
how a ViewModel can expose commands to a View,
thus allowing the view to consume its functionality.
If you aren't familiar with commanding,
I recommend that you read Brian Noyes's comprehensive 2008 article,
"Advanced WPF: Understanding Routed Events and Commands in WPF,"
. the MVVM pattern is also popular because
ViewModel classes are easy to unit test,
as views and unit tests are just
two different types of ViewModel consumers.
When an application's interaction logic
lives in a set of ViewModel classes,
you can easily write code that tests it.
Having a suite of tests for an application's ViewModels
provides free and fast regression testing,
which helps reduce the cost of
maintaining an application over time.
In addition to promoting the creation of
automated regression tests,
the testability of ViewModel classes can assist in
properly designing user interfaces that are easy to
skin[ create new view for .]
When you are designing an application,
you can often decide whether something should be
in the view or the ViewModel
by imagining that you want to write a unit test
to consume the ViewModel.
If you can write unit tests for the ViewModel
without creating any UI objects,
you can also completely skin the ViewModel
because it has no dependencies on specific visual elements.
Lastly, for developers who work with visual designers,
using MVVM makes it much easier to create a
smooth designer/developer workflow.
Since a view is just an arbitrary consumer of a ViewModel,
it is easy to just rip one view out
and drop in a new view to render a ViewModel.
This simple step allows for rapid prototyping
and evaluation of user interfaces made by the designers.
The development team can focus on
creating robust ViewModel classes,
and the design team can focus on
making user-friendly Views.
Connecting the output of both teams can involve
little more than ensuring that the
correct bindings exist in a view's XAML file.
MVVM was built around the WPF architecture,
and encapsulates elements of
MVC, MVP, and PM design patterns.
This article will compare and contrast
MVC, MVP, and MVVM,
and suggest which pattern to use based on
your technology of choice
and the problem that you are trying to solve.
MVC
A careful reader of the “Gang of Four” book will notice that
MVC is not referred to as a design pattern
but a “set of classes to build a user interface”
that uses design patterns such as
Observer, Strategy, and Composite.
The views and models use the Publish-Subscribe protocol
- when Model data is changed, it will update all Views
via the Observer design pattern that defines the
one-to-many relationship between the
Subject and the Observers;
if the Subject is changed all Observers are updated.the .Net's MVVM vs Cocoa's MVC:
The Subject maintains the list of the Observers
and can attach and detach objects to the list.
The Observer in return exposes an
Update method on its interface
that Subject can use to update all objects it observes.
Now we know that the Model acts as a Subject
from the Observer pattern
and the View takes on the role of the Observer object.
In the other relationship of the MVC,
the View is a Context
and the Controller is a Strategy object.
MVP
Potel questioned the need for the MVC's Controller;
He noticed that modern user interfaces
already provide most of the Controller functionality
within the View class,
and therefore the Controller seems a bit redundant.
. in MVP, user actions can be classified as
# raising events -- Interactor class --
# {component selection, command requests}
which operate on selected portions of the Model .
. the Presenter encapsulates these as the classes
Selection, Command, and Interactor.
Presenter in MVP encapsulates commands,
whereas, the Presentation Model's AppModel
does not encapsulate commands .
The Presenter can directly access
both the View and the Model .
There are different flavours of MVP,
[ meaning that competing authors
co-opted the term .]
. MVP uses the MVC`Observer pattern;
[where model notifies and view accesses model;]
however, the Presenter can access the View directly.
[MVC's model never accesses the View directly .]
. Microsoft made this a part of the
Composite Application Blocks (CAB) framework .
Presentation Model
. Martin Fowler saw MVC's
most fundamental idea
is a separation of
# the presentation objects (view)
# the domain model objects (model)
-- the Separated Presentation pattern.
. MVC'c Observer pattern is viewed as a
Synchronization choice {Observer, Flow}.
He also points us towards
two quite different descriptions of MVP
– one by Potel, and the other one by
Bower and McGlashan.
. Fowler's Supervising Controller
refers to Potel's MVP (removal of the Controller
and delegating more work to the View).
. Fowler's Passive View
refers to Bower & McGlashan's MVP
(the ability of the Presenter to update the View directly).
Fowler's Presentation Model
refers to the solution for a { MVC, MVP } problem:
persistence of the View’s state;
ie, if the Model does not know anything about
the user's interactions (UI -- the View's job),
and the View does not implement any domain logic
(because that's the Model's job),
then where would we store the state of
the View’s elements such as selected items?
VisualWorks-Smalltalk team's App'Model
is a class that can store this state .
the AppModel class acts as an MVC`Model for the View,
and it acts as an MVC`View for the domainModel .
MVVM
John Gossman's MVVM (model-view-viewmodel)
was built around [symbolic] UI architecture
[ where the View's design is declared by xml
in the same web page design is declared by html .
. the other way to do UI is programmatically,
where a javascript coder programs the view
by calling functions that compose widgets .]
Just like an MVC`view
the MVVM`View can bind to the data,
but without any coding at all,
[ XAML, a sort xml, describes the view,
and the run-time system makes it so .]
Obtuse May 3 '11:other comparisons of mvc:
. it seems Apple's MVC is more like MVP[presenter],
and MVVM is a subtle twist on MVP
that relates to designing GUIs in a GUI specific language
JasonD Feb 20:
. the differences are in the direction of the binding:
In MVVM, the View binds to
properties on a ViewModel object (V -> VM).
Change the ViewModel object's properties,
and with NotifyPropertyChanged,
the View magically updates itself.
The View passively reads off
properties in the View Model object,
whereas the ViewModel knows nothing
about the View
- you could delete the View
and the ViewModel would still work.
This gives you the flexibility to rewrite views
and have them "just work"
without changing a line of viewmodel code.
. In MVC under Cocoa (iOS),
the view controller binds itself to the view (VC -> V)
through explicit IBAction/IBOutlet properties
- you have a direct reference in your view controller
to the view objects: Delete the View,
and the ViewController will throw runtime exceptions.
You directly tell a control on the view
to change in your view controller,
and the ViewController has intimate knowledge about
the internals of the View.
With Cocoa using the MVC pattern,
you are directly "controlling" the view;
In MVVM/WPF, you are having the view control
update itself by watching for
changes to the ViewModel object
- the binding is the other way around and passive.
WPF without MVVM is just like Cocoa MVC for iOS,
and feels a bit like ASP.NET forms.
. Cocoa for OSX does have a
more MVVM-like binding strategy available,
but that isn't available on iOS.
mvc vs model-view-presenter(mvp):Joel Wenzel 2011`MVVM vs MVP vs MVC:
. this shows that while mvc notifies views directly,
mvp is notifying a view's presenter .
. in both cases the strategy object
manipulates the model .
The concise explanation:
. Similarities bewteeen MVVM, MVP, MVCstackoverflow's discussion of mvvm:
include having a Model, a View,
and some sort of methods for
separating the view from the model;
(eg, Controller, ViewModel, Presenter).
. the Key Differences amount to
how this separation occurs .
Controller (ASP.NET MVC)
One controller will be responsible for
initiating the display of many different views.
. how much should the views
communicate with the model? .
ViewModel (WPF, knockout js)
One view model per view;
Views are binding to the view model’s functions .
Presenter (WinForms) [abstract view]
One Presenter per view;
rather than use a bind mechanism,
each view implements an interface
[making all widget toolkits look the same
when the presenter interacts with the view;
requires synchronizing presenter with view].
. each view has a reference to the presenter
to forward messages to it .
-- see also
MVVM vs MVP vs MVC: The differences explained .
HiTech Magic Aug 22 '10 at 9:19
. to be independantly testable, and reusable when needed,
a view-model has no idea what view is displaying it,
but more importantly no idea
where its data is coming from.
Even in MVVM,
We still create controllers, as and when needed,
to control the overall logic of our applications.
. controllers will typically contain all processing logic
to decide which view models to use,
and what data to display in which views .
. the main benefit of the ViewModel pattern
is to remove code from XAML* code-behind
to make XAML editing a more independent task.
*: XAML (Extensible Application Markup Language)
is used for initializing structured values and objects.
and forms a user interface markup language
to define UI elements, data binding, eventing, etc;
The basic M-V-C-VM guidelines we follow are:
* Models hold the actual data;
Views display a certain shape of data
having no idea where the data comes from.
* ViewModels are like views
plus they hold commands .
* Controllers listen for, and publish, events;
they control what data is seen and where,
they provide the ViewModel's command's methods,
so that the ViewModel is actually reusable.
. in the Sculpture code-gen framework,
controllers implement MVVM
and also separate all use-case logic .
Tomasz Zielinski Jul 13 '11 at 22:59:
. MVC is used to architect the whole (web) application,
while MVVM is used within the View of the MVC system;
So the whole paradigm would be M(V-VM)C .
No comments:
Post a Comment