MVP

I'm developing an app to study the MVP pattern.
Basically, for every form I have:
A Presenter class, a View interface and a form that implements this 
interface.
An instance of View is passed on the Presenter's constructor and in this 
moment the Presenter sets itself on the 'Presenter' property of the View. 
So, the Presenter knows the View interface and vice-versa.
First doubt: I have a login form. What should its model be? I think it could 
the a list of the users retrieved from the database. Am I wright?
If so, where is the best place to load such list? Inside the presenter (i.e. 
the presenter itself is responsible for querying the database) or outside 
the presenter and passing that list on the presenter's constructor?

Second doubt: Imagine that there is a button on my login form to register a 
new user. When clicked, a new form must be showed. Is login presenter 
responsible for instantiate the correct view and presenter for this 
operation and show the form?
So, I would have something like this:
procedure TLoginViewImpl.NewUserButtonClick(Sender: TObject);
begin
  Presenter.NewUser;
end;

...

procedure TLoginPresenter.NewUser;
var
  View: INewUserView;
  Presenter: INewUserPresenter;
begin
  View := ...............;
  Presenter := TNewUserPresenter.Create(View);
  Presenter.Execute;
end;

Is this correct? If so, what's the best way to instantiate the NewUserView? 
If I hardcode something like "View := TNewUserViewImpl.Create;", I
won't be 
able to change the view implementation during the tests. 

Magno Machado a écrit :

> I'm developing an app to study the MVP pattern.

Have you seen the articles on MVP on my website? They are a bit dated 
and my designs have evolved since then but they should give you an insight.

> Basically, for every form I have:
> A Presenter class, a View interface and a form that implements this 
> interface.
> An instance of View is passed on the Presenter's constructor and in this 
> moment the Presenter sets itself on the 'Presenter' property of the 
> View.

You don't appear to be passing in the Model to Presenter's constructor 
as well as the View.

> So, the Presenter knows the View interface and vice-versa.

No, the View should not need to have knowledge of the Presenter.

> First doubt: I have a login form. What should its model be?

IMO, the Model is essentially a "GateKeeper" which has User and
Password 
properties and an internal mechanism which looks up the User and 
Password in the SecurityList Before setting the "Accept" or
"Valid" 
property on the Model.

> I think it 
> could the a list of the users retrieved from the database. Am I wright?

No, the Model should have no knowledge of the database, that should be 
further separated (ideally).

> If so, where is the best place to load such list? Inside the presenter 
> (i.e. the presenter itself is responsible for querying the database) or 
> outside the presenter and passing that list on the presenter's
constructor?

It is usual to have a Persistence Layer which looks after and hides the 
database. The interface to this layer should be the only means of 
retrieving and saving objects.

> Second doubt: Imagine that there is a button on my login form to 
> register a new user. When clicked, a new form must be showed. Is login 
> presenter responsible for instantiate the correct view and presenter for 
> this operation and show the form?

MVP should also include Interactors, which are held by the Presenter and 
responsible for responding to UI inputs from buttons or edits. It is 
these Interactors that should create further Presenters if required.

> Is this correct? If so, what's the best way to instantiate the 
> NewUserView? If I hardcode something like "View := 
> TNewUserViewImpl.Create;", I won't be able to change the view 
> implementation during the tests.

I get the Presenter to instantiate its View internally for forms but to 
take a control as the View parameter to the Presenter's constructor.

Does that start to help?

Joanna

-- 
Joanna Carter [TeamB]

> No, the View should not need to have knowledge of the Presenter.
But what would be the problem on it?

>> First doubt: I have a login form. What should its model be?
>
> IMO, the Model is essentially a "GateKeeper" which has User and
Password 
> properties and an internal mechanism which looks up the User and Password 
> in the SecurityList Before setting the "Accept" or
"Valid" property on the 
> Model.
So the login logic should be on the model? I thought the model as only data, 
with no logic at all

> It is usual to have a Persistence Layer which looks after and hides the 
> database. The interface to this layer should be the only means of 
> retrieving and saving objects.
Yes, but who is the responsible for use this persistence layer for loading 
the needed data? The presenter?

> MVP should also include Interactors, which are held by the Presenter and 
> responsible for responding to UI inputs from buttons or edits. It is these

> Interactors that should create further Presenters if required.
Hum...
So, there would be an property on the Presenter which I have to assign with 
an object that will respond to the 'register new user' action (In that 
exemple of login screen)?
If yes, when should this property be assigned? 

>Are you using the full MVP pattern complete with Commands, Selection and 
>Interactors, or are you using, what I would call, the MVC pattern where all

>the interaction is done in the Presenter
I'm trying to understand and use MVP, but based on what I've read here, I 
guess I'm using the "MVC pattern where all the interaction is done in the 
Presenter".
Basically, when something happens on the UI (the user clicks on a button, 
for exemple), the view calls a method on the presenter, and then everything 
is done on the presenter.

I've started to study by the Martin Fowler's arcticle about MVP, and I 
haven't read anything about command or interactor there.

"Joanna Carter [TeamB]" <joanna@nospam.for.me> escreveu na
mensagem 
news:47f248ea@newsgroups.borland.com...
> Joanna Carter [TeamB] a écrit :
>
> A thought just struck me. Are you using the full MVP pattern complete with

> Commands, Selection and Interactors, or are you using, what I would call, 
> the MVC pattern where all the interaction is done in the Presenter; 
> essentially making the Preseter nothing more than MVC concept of a 
> Controller?
>
> Joanna
>
> -- 
> Joanna Carter [TeamB]
> Consultant Software Engineer 

Magno Machado a écrit :

>> No, the View should not need to have knowledge of the Presenter.
> But what would be the problem on it?

 From much experience with MVP, some Presenters end up being 
specifically written for a particular View class; tying the View to a 
particular Presenter as well as the Presnter to a particular View would 
be even more restrictive and mean that you could not use alternative 
Presenters for a given View. e.g. we have a "form" which can be used 
either standalone or docked in a panel on another form; if that "form"

had a dependency on the Presenter we could not use it on the panel as 
this kind of use would not require a Presenter, just an Interactor.

> So the login logic should be on the model? I thought the model as only 
> data, with no logic at all

Most certainly; all business logic should be in the Model. The Model 
should contain values which need displaying/editing and also Commands 
which will be called (via interactors) from the buttons or menu items in 
the UI.

A properly separated MVP should include forms that have absolutely no 
code at all on them; all code that reacts to buttons, leaving edits, 
etc, should be either in the related Command in the Model or in the 
Interactor for each related control, those "property/command" 
interactors should, in turn, be held in the Interactor for the overall 
form or View. The View's overall Interactor will be held in the 
Presenter for that View. It is the job of the Presenter to hook up the 
main Interactor to the View; then the main Interactor is responsible for 
hooking up the "sub-interactors".

>> It is usual to have a Persistence Layer which looks after and hides 
>> the database. The interface to this layer should be the only means of 
>> retrieving and saving objects.
> Yes, but who is the responsible for use this persistence layer for 
> loading the needed data? The presenter?

No, the calls to the Persistence mechanism are usually made from the 
Interactor for a given button or, sometimes, in the Interactor for 
something like a combo box, sometimes, as part of the Model's behaviour 
such as Validation.

Your UI should not know anything at all about the Presenter or the Model 
or any of the Interactors; it really is meant to be just a dumb View; 
all the intellignet stuff is done in the Interactors.

>> MVP should also include Interactors, which are held by the Presenter 
>> and responsible for responding to UI inputs from buttons or edits. It 
>> is these Interactors that should create further Presenters if
required.
> Hum...
> So, there would be an property on the Presenter which I have to assign 
> with an object that will respond to the 'register new user' action (In 
> that exemple of login screen)?

As I said earlier, any button on the form should be handled by an 
Interactor; this "Command Interactor" will normally be held as part of
a 
list of Interactors, inside an Interactor for the whole form. This 
"outer" or Form Interactor, will respond to things like the closing of

the form, depending on whether the form was opened modally or not.

> If yes, when should this property be assigned?

The Presenter is responsible for creating approriate Interactore when it 
is constructed. The Model and the View are passed to the contructor and 
it is there that the Presenter creates and hooks up the Interactor that 
it is responsible for creating and holding, passing the Model and View 
to its constructor. This overall Interactor should then iterate through 
the properties and edits, creating and Edit Interactor for each 
property; then it should go on to create Command Interactors for each of 
the Commands in the Command Set and hooking them up to the button that 
fires the Command. Each Command is mapped, if necessary, on to the 
appropriate method in the subject of the Model.

Joanna

-- 
Joanna Carter [TeamB]