Board index » delphi » Martin Fowler's MVP vs Joanna's MVP

Martin Fowler's MVP vs Joanna's MVP


2006-04-22 11:59:21 PM
delphi271
Hi,
I have studied Joanna's MVP 12 month ago and have used the concept to
build some presenters. Joanna MVP concept consists of the following:
1. Presenter
2. Model
3. View
4. Interactor
5. Command
6. Command Set
7. Selection
The Model and View use Observer patterns to perform the update. The
Interactor updates Model from View's changes. The Command /CommandSet
resides in Model and will perform specific task on model. The Selection
also resides in Model and is used by Command to perform some specific
tasks on items in model. These are what I learned from Joanna's MVP.
I have created some MVP and it goes okay. However, I still feel it isn't
that perfect at all. The concepts of Interactors is hard to code in
Delphi/VCL and some involve changing the WndProc as proposed by Joanna.
The concepts of Selection doesn't fit well into simple model that don't
have list of items. The command/command Set also seems strongly relate
to the UI element like Button/MenuItem. And I found Presenter seems do
nothing here and it is just an object to hold a list of interactors. The
role of presenter in MVP seems too simple from my understanding.
Perhaps these are what MVP about...
Not Until I read the Martin's Fowler MVP article, I suddenly get
understand what the MVP does... The MVP proposed by Martin doesn't
mentioned the concept of command, commandset, selection and interators.
It only mention MVP - model, view, presenter.
I am not too sure if Joanna's MVP illustration is the most complete
silver bullet in the MVP context. Or the Martin's MVP also fit well in
the case.
Here is the Martin's MVP:
www.martinfowler.com/eaaDev/ModelViewPresenter.html
Thank you.
--
Best regards,
Chau Chee Yang
E Stream Software Sdn Bhd
URL: www.sql.com.my
SQL Financial Accounting
 
 

Re:Martin Fowler's MVP vs Joanna's MVP

Hey Chau,
I alread had read Martin's MVP, and I think that is a unfinished
document.
I have a running MVP, based on some JC concepts and other papers that I
found in internet, it was implemented by my way in that moment, based
on what I could undertand and my delphi knowledment, I dont use
interfaces and dont use WndProc at all.
Now Im finishing to rewrite, after read a lot about that and learn
better how to work with interfaces, in this rewrite im rewring
everything including OPF.
This job is almost done, that is my approach:
1) MVP is like the most MVP
2) CommandSet/Command/Interactors is still a dark side that trying to
figure out a better way to implement
3) Selection is Ok
4) OPF is OK, only need more tests with 3 layers
5) I use factorys to create all UI, have a abstract class and load the
implemented as plugins to generate all UI.
6) My Interactors use common events, not WndProc, I a thread with JC I
remember that I talk, and if I not wrong, she agrees that the of one or
other approach depend of ur needs, I think that events can handle all
my needs.
Presenter, is just a aggregator of other parts to abstract the needed
of Model knows about View and vv. Without this, Model will exposed to
View or View will be exposed to Model, the abstraction here give more
reusable code, I thing that this concept is ok.
About Selection, I do like that:
1) ObjectList ->Selection = Object
2) Object ->Selection = Attribute (that I call Member in my framework)
I think that more clarification about better way of implement
Commands/Interactors and the Selection cold give to us a soft way to
keep working on that. But what is the better way? maybe should we share
ur experiences here, or other place, so each one cold get what is the
better way for your needs.
Regards,
Cesar Romero
Chau Chee Yang writes:
Quote
Hi,

I have studied Joanna's MVP 12 month ago and have used the concept to
build some presenters. Joanna MVP concept consists of the following:

1. Presenter
2. Model
3. View
4. Interactor
5. Command
6. Command Set
7. Selection

The Model and View use Observer patterns to perform the update. The
Interactor updates Model from View's changes. The Command /CommandSet
resides in Model and will perform specific task on model. The
Selection also resides in Model and is used by Command to perform
some specific tasks on items in model. These are what I learned from
Joanna's MVP.

I have created some MVP and it goes okay. However, I still feel it
isn't that perfect at all. The concepts of Interactors is hard to
code in Delphi/VCL and some involve changing the WndProc as proposed
by Joanna. The concepts of Selection doesn't fit well into simple
model that don't have list of items. The command/command Set also
seems strongly relate to the UI element like Button/MenuItem. And I
found Presenter seems do nothing here and it is just an object to
hold a list of interactors. The role of presenter in MVP seems too
simple from my understanding.

Perhaps these are what MVP about...

Not Until I read the Martin's Fowler MVP article, I suddenly get
understand what the MVP does... The MVP proposed by Martin doesn't
mentioned the concept of command, commandset, selection and
interators. It only mention MVP - model, view, presenter.

I am not too sure if Joanna's MVP illustration is the most complete
silver bullet in the MVP context. Or the Martin's MVP also fit well
in the case.

Here is the Martin's MVP:

www.martinfowler.com/eaaDev/ModelViewPresenter.html

Thank you.
--
 

Re:Martin Fowler's MVP vs Joanna's MVP

Hi Cesar Romero,
I am not sure if this MVP concept do the task:
The presenter coordinate model and view. The presenter has an event
handler that hook to view's Changed event. The presenter is an observer
of the model.
1. If the view has been updated by any UI gestures, it will trigger a
Changed event.
2. The changed event was hooked by a handler written in presenter.
3. The event handler change the model if necessary
4. The model get updated and may notify the observers (presenter), the
presenter will update the view via Coarse-grained synchronization or
fine-grained synchronization.
This concept is different compare to Joanna's MVP. I am confuse if it
is necessary for the view to be an observer of model? Or should the
presenter be the observer of model?
--
Best regards,
Chau Chee Yang
E Stream Software Sdn Bhd
URL: www.sql.com.my
SQL Financial Accounting
 

Re:Martin Fowler's MVP vs Joanna's MVP

Quote
Not Until I read the Martin's Fowler MVP article
At the very end of Fowler's article, he mention that "The basic term and
idea seemed to originate from Taligent, which inevitably is rather more
complex." If you read the Taligent's paper you will notice it is more in
accordance to Joanna´s work. Thus, it seems that Fowler's intention was
to give only a rough idea about MVP- as Taligent's paper does at the
begining -but Joanna went on that paper and did the hard work.
 

Re:Martin Fowler's MVP vs Joanna's MVP

Hi Chau,
I made my View observer of Model.Value
That could be a Item of a list or a member of a object, in my famework
derivated from IValueType.
My Presenter hold Model, View and Interactors
In Create In set default Selection and Presenter Bind the View to
correspondent Model.Value and Menus/Buttons to CommandSet/Commands
When a interactor is notified by UI changes/gestures the interactor
triggers the Command.Execute passing Selection in Target parameter.
[]s
Cesar
Chau Chee Yang writes:
Quote
Hi Cesar Romero,

I am not sure if this MVP concept do the task:

The presenter coordinate model and view. The presenter has an event
handler that hook to view's Changed event. The presenter is an
observer of the model.

1. If the view has been updated by any UI gestures, it will trigger a
Changed event.

2. The changed event was hooked by a handler written in presenter.

3. The event handler change the model if necessary

4. The model get updated and may notify the observers (presenter),
the presenter will update the view via Coarse-grained synchronization
or fine-grained synchronization.

This concept is different compare to Joanna's MVP. I am confuse if
it is necessary for the view to be an observer of model? Or should
the presenter be the observer of model?
--
 

Re:Martin Fowler's MVP vs Joanna's MVP

Hi Cesar Romero:
Quote
I made my View observer of Model.Value
That could be a Item of a list or a member of a object, in my famework
derivated from IValueType.

My Presenter hold Model, View and Interactors
In Create In set default Selection and Presenter Bind the View to
correspondent Model.Value and Menus/Buttons to CommandSet/Commands

When a interactor is notified by UI changes/gestures the interactor
triggers the Command.Execute passing Selection in Target parameter.
Your Model is subject to View, and the View know the Model via the
Update method:
procedure TView.Update(S: ISubject);
begin
ViewValue := (S as IModel).Value;
end;
In Martin's MVP, the presenter is observer of model. The View knows
nothing about model or presenter. Any changes on View will trigger an
event. The event was hooked by presenter's event handler. The Presenter
is the one who should update the model's value. When the model's value
change, it will notify the observer (in this case, the presenter is
observer). The presenter will pull the value from model and update the view.
--
Best regards,
Chau Chee Yang
E Stream Software Sdn Bhd
URL: www.sql.com.my
SQL Financial Accounting
 

Re:Martin Fowler's MVP vs Joanna's MVP

"Chau Chee Yang" <XXXX@XXXXX.COM>a écrit dans le message de news:
XXXX@XXXXX.COM...
| I have created some MVP and it goes okay. However, I still feel it isn't
| that perfect at all. The concepts of Interactors is hard to code in
| Delphi/VCL and some involve changing the WndProc as proposed by
| Joanna.
The Interactors are there to handle any event happening in a visual control
and can either handle straightforward events or it can intercept the WndProc
only if that is deemed necessary to provide correct hendling for things like
stopping focus from leaving an edit if validation of the edit's content
fails.
If I use .NET WinForms controls, then intercepting the WndProc is no longer
necessary as the event model of all controls is much more complete and
includes a Validating event which allows us to return a "cancel" flag to the
control, thus stopping focus leaving the control.
The purpose of the Interactors is to provide a place for event code from
controls without having to place that code on the form. Coding Interactors
should be as simple as coding event handlers on a form.
| The concepts of Selection doesn't fit well into simple model that don't
| have list of items.
In the case of a simple model, then the Selection is deemed to be the value
that is held in the model.
TModel = class
public
property Selection: TSelection ... ;
...
end;
TObjectModel = class
private
fValue: TObject;
public
constructor Create(Value: TObject);
end;
constructor TObjectModel.Create(Value: TObject);
begin
fValue := Value;
Selection.Add(fValue)
end;
TListModel = class
private
fValue: TObjectList;
public
constructor Create(Value: TObjectList);
end;
constructor TListModel.Create(Value: TObjectList);
begin
fValue := Value;
// don't add anything to the selection
// as nothing has been selected in the View yet
end;
| The command/command Set also seems strongly relate
| to the UI element like Button/MenuItem.
Certainly, the Command concept is usually connected with such UI elements,
but don't forget that menu items can be on a context sensitive popup menu on
a single edit control.
You may not have any Commands on a single object/property but you can have a
popup menu on a list box that allows you to Add/Insert/Delete items and it
is for situations like this that the Command/set comes into its own.
| And I found Presenter seems do
| nothing here and it is just an object to hold a list of interactors. The
| role of presenter in MVP seems too simple from my understanding.
The Presenter is there to hold the Model and View and to connect them up, as
well as holding any relevant Interactors.
When "presenting" an object, the calling syntax should be something like
this :
procedure T... AddCustomer;
var
cust: TCustomer;
presenter: TPresenter;
begin
cust := TCustomer.Create;
presenter := TFormPresenter.Create(cust, TCustomerForm);
end;
Calling the presenter's constructor not only creates the presenter, it goes
on to create a Model for the TCustomer value, and an instance of the
TCustomerForm form class that was passed in to the constructor. It would
then go on to hook up any buttons on the form to the Command Set in the
Model and finally, show the form.
Apart from linking up the Customer to the form that will display it, the
Presenter is also responsible for creating and holding a list of Control
Presenters, one for each property of the Customer object, so that each
property is linked.
Of course, because the Control Presenters need an object to act as the value
for the Model, you would need to use a Value Type Framework (Google for
previous discussions in this group on this topic) behind the public
properties of your objects.
You should end up with a form with absolutely no code on it, and a Presenter
that knows how to create a form and link up all the relevant components and
show the form.
Saving the object that was edited in the form is the job of the Save Command
in the Model that is called by the Interractor attached to the Save button
on the form.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re:Martin Fowler's MVP vs Joanna's MVP

"Chau Chee Yang" <XXXX@XXXXX.COM>a écrit dans le message de news:
444db298$XXXX@XXXXX.COM...
| In Martin's MVP, the presenter is observer of model. The View knows
| nothing about model or presenter. Any changes on View will trigger an
| event. The event was hooked by presenter's event handler. The Presenter
| is the one who should update the model's value. When the model's value
| change, it will notify the observer (in this case, the presenter is
| observer). The presenter will pull the value from model and update the
view.
Martin Fowler's article is really the MVC pattern. It does not separate out
the concepts of Interactor, Selection and Command Set, all of which
distinguish MVP from MVC.
See my reply to your first post in this thread for more comments.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re:Martin Fowler's MVP vs Joanna's MVP

"Chau Chee Yang" <XXXX@XXXXX.COM>a écrit dans le message de news:
XXXX@XXXXX.COM...
| The presenter coordinate model and view.
Correct.
| The presenter has an event handler that hook to view's Changed event.
| The presenter is an observer of the model.
Not true, the Presenter should not handle any events directly, neither is it
an Observer of anything except nested property presenters.
| This concept is different compare to Joanna's MVP. I am confuse if it
| is necessary for the view to be an observer of model? Or should the
| presenter be the observer of model?
The View should be an Observer of the View that is held in the Model.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re:Martin Fowler's MVP vs Joanna's MVP

Joanna Carter [TeamB] writes:
Quote
| This concept is different compare to Joanna's MVP. I am confuse if it
| is necessary for the view to be an observer of model? Or should the
| presenter be the observer of model?

The View should be an Observer of the View that is held in the Model.
I don't understand "The View should be an Observer of the View that is
held in the Model". Can you elaborate more about it?
--
Best regards,
Chau Chee Yang
E Stream Software Sdn Bhd
URL: www.sql.com.my
SQL Financial Accounting
 

Re:Martin Fowler's MVP vs Joanna's MVP

Joanna Carter [TeamB] writes:
Quote
"Chau Chee Yang" <XXXX@XXXXX.COM>a écrit dans le message de news:
444db298$XXXX@XXXXX.COM...

| In Martin's MVP, the presenter is observer of model. The View knows
| nothing about model or presenter. Any changes on View will trigger an
| event. The event was hooked by presenter's event handler. The Presenter
| is the one who should update the model's value. When the model's value
| change, it will notify the observer (in this case, the presenter is
| observer). The presenter will pull the value from model and update the
view.

Martin Fowler's article is really the MVC pattern. It does not separate out
the concepts of Interactor, Selection and Command Set, all of which
distinguish MVP from MVC.

See my reply to your first post in this thread for more comments.
If the View is an observer of model, then the view know the model in the
update method that couple the model and view together. Don't you think
this design is a bad approach?
If the presenter is the coordinator to model and view, it updates model
and view. The model and view doesn't know each other. This seems a
favor design in the context of mvp.
--
Best regards,
Chau Chee Yang
E Stream Software Sdn Bhd
URL: www.sql.com.my
SQL Financial Accounting
 

Re:Martin Fowler's MVP vs Joanna's MVP

"Chau Chee Yang" <XXXX@XXXXX.COM>a écrit dans le message de news:
XXXX@XXXXX.COM...
| I don't understand "The View should be an Observer of the View that is
| held in the Model". Can you elaborate more about it?
I'm sorry, that should have read "the View should be an Observer of the
Value that is held in the Model"
See references to the Value Type Framework for more info on that kind of
thing.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re:Martin Fowler's MVP vs Joanna's MVP

"Chau Chee Yang" <XXXX@XXXXX.COM>a écrit dans le message de news:
444e103b$XXXX@XXXXX.COM...
| If the View is an observer of model, then the view know the model in the
| update method that couple the model and view together. Don't you think
| this design is a bad approach?
Not at all. You have to be able to design Views to display specific data
types, whether they be simple values like Integer, Date, String, etc or
complex types like Customer, Order, etc.
Although you can design a View that is specific to a simple type, you cannot
expect a single View to be able to display any complex type. Unless, that
is, you design an auto-layout form; not a very nice way doing things IMO.
| If the presenter is the coordinator to model and view, it updates model
| and view. The model and view doesn't know each other. This seems a
| favor design in the context of mvp.
The Presenter is a co-ordinator in that it is responsible for aggregating
the Model, View, Interactors and sub-presenters, but you then have to either
vary the View to accomodate the type being displayed, or you have to write a
specific Presenter for each type.
You will notice that in the short example that I gave, the Presenter was a
generic Form Presenter that knew how to display any complex object on a
form. However, in order to be able to allow RAD design of forms specific to
any given type, then all you have to do is to pass in the type of the form
to be created and the generic Form Presenter will create an appropriate
pre-designed form and link it to the object to be edited.
In order to separate out the actual display element so that you don't have
to implement the Observer in every form you design, you can write a View
wrapper class that, in the same way that the Model wraps the Value, the View
is an Adapter between the Observer pattern and the actual form class.
TView = class(TInterfacedObject, IObserver)
private
procedure Update(subject: ISubject);
...
end;
TFormView = class(TView)
private
fForm: TForm;
public
constructor Create(formType: TFormClass);
property OnOK: TNotifyEvent ... ;
property OnCancel: TNotifyEvent ... ;
...
end;
then the Interactors can be linked to the On... events of the View adapter
rather than those directly attached to the components of the form.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re:Martin Fowler's MVP vs Joanna's MVP

Joanna,
Quote

TView = class(TInterfacedObject, IObserver)
private
procedure Update(subject: ISubject);
...
end;

TFormView = class(TView)
private
fForm: TForm;
public
constructor Create(formType: TFormClass);
property OnOK: TNotifyEvent ... ;
property OnCancel: TNotifyEvent ... ;
...
end;

then the Interactors can be linked to the On... events of the View adapter
rather than those directly attached to the components of the form.
Can you expand on this a little, e.g. show typical code for each of the
events.
David McCallum
 

Re:Martin Fowler's MVP vs Joanna's MVP

Joanna Carter [TeamB] writes:
Quote
"Chau Chee Yang" <XXXX@XXXXX.COM>a écrit dans le message de news:
XXXX@XXXXX.COM...

| I don't understand "The View should be an Observer of the View that is
| held in the Model". Can you elaborate more about it?

I'm sorry, that should have read "the View should be an Observer of the
Value that is held in the Model"

See references to the Value Type Framework for more info on that kind of
thing.
Yes. that make more sense and able to split the model and view. By using
the Value Type Framework, that simple implied that the Value Class need
to implement the ISubject interface:
TIntegerValue = class(TValue, IIntegerValue, ISubject)
property Value: integer;
end;
Thus, in the View.Update method:
procedure TView.Update(const S: ISubject);
begin
FEdit.Value := (S as IIntegerValue).Value;
end;
Correct me if I am wrong.
--
Best regards,
Chau Chee Yang
E Stream Software Sdn Bhd
URL: www.sql.com.my
SQL Financial Accounting