MVC pattern doubts

[Santi]

Hi,

If I am correct the MVC basics are:

The primary goal is to decouple the model from the views and controller.

- Model: Holds data and business logic.
- View: represents data and queries the model.
- Controller: Responds to user input, sends change notifications to the
model and to the views.

When the user clicks to open an edit view the controller instantiates
it. If the user changes the view's data, then the controller will pick
the data and notify it to the model. Then the controller will notify all
it's registered views that the model has changed and the views will
query the model.

¿Why don't the view notify the model directly since it holds a reference
to it?
¿What happens if the edit view needs to validate some user input data
before closing, for example that the code the user has just entered is
not repeated in the database? ¿wouldn't be more convenient if the view
queries directly the model? After some "googling" my impression is that
this is not recomended, but ¿how should it be done then? ¿is it
necessary the trip from the view to the controller and from the
controller to the model, even though the view holds a reference to the
model directly?


What I have in mind to do in my c# application is, using delegates and
events:

- The controller creates and registers the views and then wires itself
to the user interface notification events that the views raise. The
model also wires the views to the model's Changed event.

- The views hold a reference to the model and can query it or call its
"store this entity" method directly. If there is for example a check
needed to be done throug the model, for example if a value that the user
has entered is repeated, it can also do it directly. When they recive
the "ModelChanged" event they update themselves querying the model.

- The model is decoupled from de view and the controller, therefore it
can be tested separately. It has some standard public functions to be
queried and to store entities. It also raises a 'ModelChanged' evend


¿Is this correct? ¿I am misunderstanding something?

sorry for the long post and thank you very much in advance,
Santi

 

[Ben]

Before making a lot of effort... Take a look at Microsoft.ApplicationBlock.UIProcess.
It's a very nice base for creating a MVC-like application.

Gr,
Cybenny


Hello Santi,

 

[Jeff Louie]

Santi... Sometimes seeing actual working code is helpful. Here is some
actual
MVC code in a framework designed as MVC. In this case I am doing
everything through the controller so that the controller knows about the
views and the model. The views and model know nothing of each other.
For
instance textViewQuery is in the View and model is the Model.

- (IBAction)doExecuteScalarid)sender {
[textViewQuery setString""];
[textViewQuery setString:[model scalarQuery:[textFieldSQL
stringValue]]];}

// Controller v0.15

#import <Cocoa/Cocoa.h>
#import "Model.h"

@interface Controller : NSObject
{
IBOutlet id buttonExecuteToString;
IBOutlet id buttonExecuteTableView;
IBOutlet id buttonExecuteScalar;
IBOutlet id buttonExecuteNonQuery;
IBOutlet id model;
IBOutlet id buttonClear;
IBOutlet id textViewQuery;
IBOutlet id textFieldURL;
IBOutlet id textFieldUserID;
IBOutlet id textFieldPW;
IBOutlet id textFieldDatabaseName;
IBOutlet id textFieldSQL;
IBOutlet id textViewProperties;
IBOutlet id tableView;
IBOutlet id dataSource;
IBOutlet id textFieldSQL1;
IBOutlet id textFieldSQL2;
IBOutlet id textFieldSQL3;
IBOutlet id textFieldSQL4;
IBOutlet id textViewTransaction;
}
- (IBAction)doExecuteStringActionid)sender;
- (IBAction)doExecuteTableViewActionid)sender;
- (IBAction)doClearActionid)sender;
- (IBAction)doConnectActionid)sender;
- (IBAction)doDisconnectActionid)sender;
- (IBAction)doExecuteScalarid)sender;
- (IBAction)doExecuteNonQueryid)sender;
- (IBAction)doAutoCommitOnid)sender;
- (IBAction)doAutoCommitOffid)sender;
- (IBAction)doBeginTransactionid)sender;
- (IBAction)doExecuteTransactionid)sender;
@end

In C#, I tend to think in M-VC or ENGINE-INTERFACE.

Regards,
Jeff
- Model: Holds data and business logic.
- View: represents data and queries the model.
- Controller: Responds to user input, sends change notifications to the
model and to the views.

 

[Joerg Jooss]

Hi,

If I am correct the MVC basics are:

The primary goal is to decouple the model from the views and
controller.

- Model: Holds data and business logic.

Holds data yes. Business logic? Possible, but not mandatory. Depending
on the application architecture, the model could consist of mere value
objects (or data transfer objects or view beans...).

- View: represents data and queries the model.

The view doesn't query the model. It receives events from the model --
it's a "push", not a "pull".

- Controller: Responds to user input, sends change notifications to
the model and to the views.

When the user clicks to open an edit view the controller instantiates
it. If the user changes the view's data, then the controller will pick
the data and notify it to the model. Then the controller will notify
all it's registered views that the model has changed and the views
will query the model.

In clasic MVC, the model publishes changes to the views directly. The
controller isn't involved.

Why don't the view notify the model directly since it holds a
reference to it?

See above -- it's the other way around:

Controller --Update()--> Model
Model --OnStateChanged()--> View

What happens if the edit view needs to validate some user input data
before closing, for example that the code the user has just entered is
not repeated in the database?

That would be plain wrong. Views render content. They don't perform any
actions. Controllers perform input validation.

wouldn't be more convenient if the view
queries directly the model? After some "googling" my impression is
that this is not recomended, but how should it be done then? is it
necessary the trip from the view to the controller and from the
controller to the model, even though the view holds a reference to the
model directly?

What I have in mind to do in my c# application is, using delegates and
events:

- The controller creates and registers the views and then wires itself
to the user interface notification events that the views raise. The
model also wires the views to the model's Changed event.

I guess you mean the right thing, but the model doesn't know any views.
Views register for for the model's state change event.

- The views hold a reference to the model and can query it or call its
"store this entity" method directly.

No. See above.

[...]

Cheers,

 

[Santi]

Thank you Joerg, I understand now how it should be done, but I still
have a doubt about the relation between the views and the model.

That would be plain wrong. Views render content. They don't perform any
actions. Controllers perform input validation.

In a List/Detail application the Detail form is a view, right? What is
the advantage of the controller picking the input information from the
detail form and sending it to the model over the detail sending the data
directly to the model, assuming that every view holds a reference to the
model.

The view doesn't query the model. It receives events from the model --
it's a "push", not a "pull".

Is it wrong to hold the views a reference to the model? The model will
still not know about the views. I thought that the model sended a
OnStateChanged to the views and then the views in response queried the
model because they held a reference to it.


regards,
Santi

 

[Joerg Jooss]

Thank you Joerg, I understand now how it should be done, but I still
have a doubt about the relation between the views and the model.



In a List/Detail application the Detail form is a view, right?

I guess it's a UI delegate -- a combination of controller and view.
Many UI frameworks (including WinForms) use this approach instead of
separating controllers and views.

What is
the advantage of the controller picking the input information from the
detail form and sending it to the model over the detail sending the
data directly to the model, assuming that every view holds a
reference to the model.

What is the advantage of eliminating the controller? If your view
already process user input, it *is* a controller.

Is it wrong to hold the views a reference to the model?

No, but not necessary.

The model will
still not know about the views. I thought that the model sended a
OnStateChanged to the views and then the views in response queried the
model because they held a reference to it.

You can communicate the model changes directly through the event.
Assuming your model communicates a ModelChangeEventArgs object, the
updated model could be exposed as a property of ModelChangeEventArgs.
You can also take a more fine grained approach by communicating only
specific parts (i.e. updated attributes) of your model.

Cheers,

 

[Santi]

I guess it's a UI delegate -- a combination of controller and view.
Many UI frameworks (including WinForms) use this approach instead of
separating controllers and views.

I think at last I get it
thank you!