Board index » delphi » MVC pattern questions

MVC pattern questions


2006-02-02 05:09:14 AM
delphi276
Hi,
I'm required to use the MVC pattern for an assignment, and have read
through various descriptions. I am still a bit confused, especially
with understanding the exact roles of the Controller and the View.
From what I read, it appears that the View is passive, and only
displays information from the Model to the user. The Controller is
resposible for all user input, and will use this to change the Model
and/or View.
To me, it seems that this way, the View and the Controller are
awefully linked. So much in fact that in many cases it seems to me
like an odd separation in many ways.
Wouldn't it be better to let the View handle all the UI (both output
and input), and call the Controller to perform the various operations?
Ie Model handles data, Controller handles logic, View handles UI. This
way you'd only have to make a new View decendant when you want to
change the UI method (console / gui / web), instead of having
decendants from both the View AND the Controller.
Could someone offer some clarification please? :)
Cheers
- Asbjørn
 
 

Re:MVC pattern questions

"Lord Crc" <XXXX@XXXXX.COM>a écrit dans le message de news:
XXXX@XXXXX.COM...
| From what I read, it appears that the View is passive, and only
| displays information from the Model to the user. The Controller is
| resposible for all user input, and will use this to change the Model
| and/or View.
|
| To me, it seems that this way, the View and the Controller are
| awefully linked. So much in fact that in many cases it seems to me
| like an odd separation in many ways.
|
| Wouldn't it be better to let the View handle all the UI (both output
| and input), and call the Controller to perform the various operations?
| Ie Model handles data, Controller handles logic, View handles UI. This
| way you'd only have to make a new View decendant when you want to
| change the UI method (console / gui / web), instead of having
| decendants from both the View AND the Controller.
IMO, there are two ways of setting up MVC.
One where the View is an Observer of the Model and the Controller is
responsible for capturing user interactions and interpreting them into calls
to the Model; changes to the Model are reflected in the View without the
involvement of the Controller.
The other is to allow the Controller to act as mediator, responding to
events in both the Model and the View used as a method of input.
I personally use the first version, it distributes the logic better and
separates concerns more appropriately
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re:MVC pattern questions

On Wed, 1 Feb 2006 22:16:05 -0000, "Joanna Carter [TeamB]"
<XXXX@XXXXX.COM>writes:
Quote
One where the View is an Observer of the Model and the Controller is
responsible for capturing user interactions and interpreting them into calls
to the Model; changes to the Model are reflected in the View without the
involvement of the Controller.
What about things that are not directly tied to the Model? In my case,
I have a simple item database. I imagine that displaying the
information of an item is a View, but what about registering a new
item? Is that also a View? Or when the user wants to enter a query, is
the "search box" part of a View? Or is that all in the controller, and
the View is "spared" for simply displaying the data?
And what about the Controller / Model split. In a simple form, should
say the Controller listen for an Ok button, when triggered gather the
info from the various controls on the form and then call a method in
the Model with this data (ala a stored procedure)? Or should the Model
be "dumb", providing a rudimentary interface for
inserting/updating/retriving data, and the Controller put the pieces
together? And what if the Controller needs additional interaction with
the user before calling the Model, is that its own responsibility or
should it use the View?
Oh, and why can not I find a page that actually explains all this in
detail? ;) All the ones I find reads like they were written by some
marketing department.
Thanks
- Asbjørn
 

Re:MVC pattern questions

"Lord Crc" <XXXX@XXXXX.COM>a écrit dans le message de news:
XXXX@XXXXX.COM...
| What about things that are not directly tied to the Model? In my case,
| I have a simple item database. I imagine that displaying the
| information of an item is a View, but what about registering a new
| item? Is that also a View? Or when the user wants to enter a query, is
| the "search box" part of a View? Or is that all in the controller, and
| the View is "spared" for simply displaying the data?
|
| And what about the Controller / Model split. In a simple form, should
| say the Controller listen for an Ok button, when triggered gather the
| info from the various controls on the form and then call a method in
| the Model with this data (ala a stored procedure)? Or should the Model
| be "dumb", providing a rudimentary interface for
| inserting/updating/retriving data, and the Controller put the pieces
| together? And what if the Controller needs additional interaction with
| the user before calling the Model, is that its own responsibility or
| should it use the View?
|
| Oh, and why can not I find a page that actually explains all this in
| detail? ;) All the ones I find reads like they were written by some
| marketing department.
I have to go to bed now, but let me leave you to think this over overnight :
MVC "components" can be nested; you can use a component for each property of
an object and nest those components inside an MVC component for the entire
object.
Take a look at the articles on MVP from my website
www.carterconsulting.org.uk
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re:MVC pattern questions

How could I implement MVC pattern with C++Builder/Delphi (VCL) to have
controller layer code out of Forms code?
Joanna Carter [TeamB] escribi?
Quote
"Lord Crc" <XXXX@XXXXX.COM>a écrit dans le message de news:
XXXX@XXXXX.COM...

| From what I read, it appears that the View is passive, and only
| displays information from the Model to the user. The Controller is
| resposible for all user input, and will use this to change the Model
| and/or View.
|
| To me, it seems that this way, the View and the Controller are
| awefully linked. So much in fact that in many cases it seems to me
| like an odd separation in many ways.
|
| Wouldn't it be better to let the View handle all the UI (both output
| and input), and call the Controller to perform the various operations?
| Ie Model handles data, Controller handles logic, View handles UI. This
| way you'd only have to make a new View decendant when you want to
| change the UI method (console / gui / web), instead of having
| decendants from both the View AND the Controller.

IMO, there are two ways of setting up MVC.

One where the View is an Observer of the Model and the Controller is
responsible for capturing user interactions and interpreting them into calls
to the Model; changes to the Model are reflected in the View without the
involvement of the Controller.

The other is to allow the Controller to act as mediator, responding to
events in both the Model and the View used as a method of input.

I personally use the first version, it distributes the logic better and
separates concerns more appropriately

Joanna

 

Re:MVC pattern questions

Hi,
Responded inside of message.
Lord Crc escribi?
Quote
On Wed, 1 Feb 2006 22:16:05 -0000, "Joanna Carter [TeamB]"
<XXXX@XXXXX.COM>writes:

>One where the View is an Observer of the Model and the Controller is
>responsible for capturing user interactions and interpreting them into calls
>to the Model; changes to the Model are reflected in the View without the
>involvement of the Controller.

What about things that are not directly tied to the Model? In my case,
I have a simple item database. I imagine that displaying the
information of an item is a View, but what about registering a new
item? Is that also a View? Or when the user wants to enter a query, is
the "search box" part of a View? Or is that all in the controller, and
the View is "spared" for simply displaying the data?
Abstractly the model has all the methods to access the information in a
database, this is code with Data Access Objects (DAO pattern), Transfer
Object (TO or VO pattern) basically. In addition Model layer has all
classes in relation to Use Cases of your company/problem to be utilized
then by the view and the controller.
Like Joanna told you there is two implementations for MVC, sincerely I
only know second, which is used in J2EE, but the concept is the same.
So, the Controller for me, in case two Joanna told you, is the entry
point for the View, to delegate if the program has to access to View to
update some view component for example or has to access to Model (open
BD, make an operation with the data, save,...) or both, it depends.
Abstractly the View, is only the User Interface(IU), doesn´t matter the
implementation, if is a web page, or Winforms, or VCL, or ASP Forms...,
so the IU connects to the Controller to pass the control of what to want
to do. So if we have an application with the Model and the Controller,
we could change the View from a VCL to WinForms or simply redesign to a
new IU without to code the program, because we only change the appearance.
With this perspective develop, maintain, add new features, reutilization
(of the application) is easier because we can change a layer without
side-lateral-efects (if all is well done of couse) in the application
like change the database engine, change the IU, and anything you can
imagine.
So more practical, in your case, you have this use cases (In the model)
"Add Item"
"Search" (any search, by id, by name,.....any want you want)
You have a form with a grid, a button to search, a button to add (This
for the view)
The union between in View and controller in RAD i don´t know how to
implement clearly, because when you respond to an event the code of the
event is placed in the code (this is what i want to talk in other post
mine about MVC), and this is not a good solution because in this case
View is linked directly with Controller, so this event should call a
Unit (controller) which lets that separation between the two layers
So, the View "call" the Controller to know which is the action of that
button and after that update the view if necessary.
Quote

And what about the Controller / Model split. In a simple form, should
say the Controller listen for an Ok button, when triggered gather the
info from the various controls on the form and then call a method in
the Model with this data (ala a stored procedure)?
Not exactly
Or should the Model
be "dumb", providing a rudimentary interface for
inserting/updating/retriving data, and the Controller put the pieces
Yes more less
together? And what if the Controller needs additional interaction with
the user before calling the Model, is that its own responsibility or
should it use the View?
Controller manages the IU too.

Oh, and why can not I find a page that actually explains all this in
detail? ;) All the ones I find reads like they were written by some
marketing department.
There is a lot, but something a bit difficult to find.
You can search
bdn.borland.com/article/0,1410,31863,00.html
This is a web page of a teacher in my university, it´s in Spanish, but
could could find a lot of information in PDF about patters, diagrams,
which can help you to answer your questions
www.tic.udc.es/~fbellas/teaching/is/index.html
www.tic.udc.es/~fbellas/teaching/pfc3/IntroPatrones.pdf
 

Re:MVC pattern questions

"Raúl Lorenzo" <XXXX@XXXXX.COM>a écrit dans le message de news:
XXXX@XXXXX.COM...
| Abstractly the model has all the methods to access the information in a
| database, this is code with Data Access Objects (DAO pattern), Transfer
| Object (TO or VO pattern) basically.
You really shouldn't have database code anywhere near the Model, that should
be in a separate layer that deals with Persistence; the Model should only
deal with instances of business classes, retrieved from the Persistence
Layer if necessary.
| So more practical, in your case, you have this use cases (In the model)
| "Add Item"
| "Search" (any search, by id, by name,.....any want you want)
| You have a form with a grid, a button to search, a button to add (This
| for the view)
This use case only applies to lists of objects, not single objects. It
really is a good idea to separate how you deal with the two.
| The union between in View and controller in RAD i don´t know how to
| implement clearly, because when you respond to an event the code of the
| event is placed in the code (this is what i want to talk in other post
| mine about MVC), and this is not a good solution because in this case
| View is linked directly with Controller, so this event should call a
| Unit (controller) which lets that separation between the two layers
| So, the View "call" the Controller to know which is the action of that
| button and after that update the view if necessary.
The View need know nothing about the Controller; it certainly doesn't need
to call it.
Events on the View can be handled by the Controller; the view is passed to
the constructor of the Controller; the handlers are hooked up to the events
in the constructor.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re:MVC pattern questions

"Raúl Lorenzo" <XXXX@XXXXX.COM>a écrit dans le message de news:
XXXX@XXXXX.COM...
| How could I implement MVC pattern with C++Builder/Delphi (VCL) to have
| controller layer code out of Forms code?
As I said in my other post, pass the Form to the Controller's constructor
and hook up the events from the Form into handlers written in the
Controller.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re:MVC pattern questions

First of all, thanks for you replies, I was away for the weekend, so
didn't have a chance to reply.
On Tue, 7 Feb 2006 17:17:54 -0000, "Joanna Carter [TeamB]"
<XXXX@XXXXX.COM>writes:
Quote
"Raúl Lorenzo" <XXXX@XXXXX.COM>a écrit dans le message de news:
XXXX@XXXXX.COM...

| Abstractly the model has all the methods to access the information in a
| database, this is code with Data Access Objects (DAO pattern), Transfer
| Object (TO or VO pattern) basically.

You really shouldn't have database code anywhere near the Model, that should
be in a separate layer that deals with Persistence; the Model should only
deal with instances of business classes, retrieved from the Persistence
Layer if necessary.
That clears the mud from the Model a bit.
Quote
| The union between in View and controller in RAD i don´t know how to
| implement clearly, because when you respond to an event the code of the
| event is placed in the code (this is what i want to talk in other post
| mine about MVC), and this is not a good solution because in this case
| View is linked directly with Controller, so this event should call a
| Unit (controller) which lets that separation between the two layers
| So, the View "call" the Controller to know which is the action of that
| button and after that update the view if necessary.

The View need know nothing about the Controller; it certainly doesn't need
to call it.

Events on the View can be handled by the Controller; the view is passed to
the constructor of the Controller; the handlers are hooked up to the events
in the constructor.
I think my main problem with using the MVC pattern for this project,
is that since the UI is console based, there's not really any events
from the View, and even if I made some funky event based mechanism,
I'd need some funky state machine in the controller to figure out what
to do with the text that arrives.
Thanks to your input (and your articles Joanna, haven't read them all,
but so far they're great!), I have got a firmer grip on MVC, and I can
see how it would work in an event based framework.
Thanks
- Asbjørn
 

Re:MVC pattern questions

Joanna Carter [TeamB] escribi?
Quote
"Raúl Lorenzo" <XXXX@XXXXX.COM>a écrit dans le message de news:
XXXX@XXXXX.COM...

| Abstractly the model has all the methods to access the information in a
| database, this is code with Data Access Objects (DAO pattern), Transfer
| Object (TO or VO pattern) basically.

You really shouldn't have database code anywhere near the Model, that should
be in a separate layer that deals with Persistence; the Model should only
deal with instances of business classes, retrieved from the Persistence
Layer if necessary.
Of course, data access is at the bottom of Model layer or better in a
Persistence Layer like you tell me. I don´t explained well.
Quote

| So more practical, in your case, you have this use cases (In the model)
| "Add Item"
| "Search" (any search, by id, by name,.....any want you want)
| You have a form with a grid, a button to search, a button to add (This
| for the view)

This use case only applies to lists of objects, not single objects. It
really is a good idea to separate how you deal with the two.

I don´t understand what do you mean
Quote
The View need know nothing about the Controller; it certainly doesn't need
to call it.

Events on the View can be handled by the Controller; the view is passed to
the constructor of the Controller; the handlers are hooked up to the events
in the constructor.
Ok, then, do the Controller invokes the View? if the view does´t call
the controller, How does the controller create the view and retrieve is
instance? Should have the view a method to retrieve this information?
In the other post you told me:
Quote
As I said in my other post, pass the Form to the Controller's constructor
and hook up the events from the Form into handlers written in the
Controller.
If the Controller is still created, how am i going to create it again
and passes the Form from View to Controller?
This points are the key.
Well, but if the IU is implemented with .NET, JAVA, Delphi or any other?
TForm doesn´t exist.
Is there any way to code a Controller the more abstract could be to
accept any kind of View Plug-In, so we could have to code the minimum or
nothing when creating the IU in other platform, technology?
 

Re:MVC pattern questions

"Joanna Carter [TeamB]" <XXXX@XXXXX.COM>writes
Quote
IMO, there are two ways of setting up MVC.

One where the View is an Observer of the Model and the Controller is
responsible for capturing user interactions and interpreting them into
calls
to the Model; changes to the Model are reflected in the View without the
involvement of the Controller.

The other is to allow the Controller to act as mediator, responding to
events in both the Model and the View used as a method of input.
I believe this is now known as MVP (Model-View-Presenter).
- Dennis
 

Re:MVC pattern questions

"Dennis Jones" <XXXX@XXXXX.COM>a écrit dans le message de news:
43e91493$XXXX@XXXXX.COM...
| I believe this is now known as MVP (Model-View-Presenter).
Sorry Dennis, but there is more to MVP than this.
In MVP, the Model has a Selection and a Command Set; the Command Set is an
observer of the Selection and should modify itself based on the current
selection and, possibly, other rules based criteria.
The Command Set can be observed by a UI structure like a popup menu or an
action panel, which will allow the user to invoke permitted Commands against
the Model.
The Model contains the actual Value or business object; it is important that
you separate out the Model from the Value as it allows clearer definition of
the real business object without the clutter of actions performed externally
on it.
The Model and View are held in the Presenter, which also holds an
Interactor.
The Interactor is the class that knows how to respond to events/messages
from the UI element in the View and translate those messages into
Commands/actions on the Model or the Value.
Interactors can be created to mediate, either directly between the UI and
the Value or the Model, depending on the nature of the use case. They can
also be nested, invoking more specialised Interactors as in the Chain of
Responsibility design pattern.
OTOH, MVC places the entire responsibility of mediating both ways on the
Controller; this means any concepts of Selection and Commands all have to be
crammed into the one place :-(
Whether you use MVC or MVP, you should always bear in mind that these
composite components can be nested inside each other, so you would have a
collection of MVC/P components, one for each property of a class, all held
inside an outer MVC/P component that is responsible for the entire object.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer