Listeners and MVC

[Jason Cavett]

I have a question about the use of listeners in MVC.

I setup my MVC so that

View has access to Model
Controller has access to View and Model
Model has indirect access to the View via Observer pattern.

What I'm wondering is - why does the Observer pattern even need to be
used? (I'm doing this part from a book I read on MVC.) It seems as
though the Controller can just act as a "pass through" for both because
it has access to both.

So, for example, if I want to open a new file and display a new file I
could do it one of two ways:

With Observer:
1. Fire Event
2. Controller calls Model to read in the file/parse/whatever.
3. Model notifies its Observers and the View (which is one of the
observers) displays the file.

Without Observer:
1. Fire Event
2. Controller calls Model to read in the file/parse/whatever.
3. Once that has happened, Controller calls the View to display the
file.

The only advantage I see to the first way is that I could potentially
create multiple views and the controller would not need to worry about
the view at all. Is this correct? Am I completely off base with how
I'm setting this up? (It seems as though everybody has their own way
of doing MVC which tends to make this confusing.)

Thanks for any help.

 

[Daniel Pitts]

I have a question about the use of listeners in MVC.

I setup my MVC so that

View has access to Model
Controller has access to View and Model
Model has indirect access to the View via Observer pattern.

What I'm wondering is - why does the Observer pattern even need to be
used? (I'm doing this part from a book I read on MVC.) It seems as
though the Controller can just act as a "pass through" for both because
it has access to both.

So, for example, if I want to open a new file and display a new file I
could do it one of two ways:

With Observer:
1. Fire Event
2. Controller calls Model to read in the file/parse/whatever.
3. Model notifies its Observers and the View (which is one of the
observers) displays the file.

Without Observer:
1. Fire Event
2. Controller calls Model to read in the file/parse/whatever.
3. Once that has happened, Controller calls the View to display the
file.

The only advantage I see to the first way is that I could potentially
create multiple views and the controller would not need to worry about
the view at all. Is this correct? Am I completely off base with how
I'm setting this up? (It seems as though everybody has their own way
of doing MVC which tends to make this confusing.)

Thanks for any help.

Basically, your model firing events is part of the controller. Wiring
up the observables and observers is the controllers job. The view's
job is to render the model whenever it is told to. The models job is to
model the domain, and the controllers job is to manage everything.

Also, keep in mind that MVC does NOT limit you to one model, one view,
and one controller. You can quite easily swap out the view and/or
controller, or have multiple controllers/views for different reasons.

 

[Jason Cavett]

JasonCavettwrote:








up the observables and observers is the controllers job. The view's
job is to render the model whenever it is told to. The models job is to
model the domain, and the controllers job is to manage everything.

Also, keep in mind that MVC does NOT limit you to one model, one view,
and one controller. You can quite easily swap out the view and/or
controller, or have multiple controllers/views for different reasons.

Okay, thanks for the explanation.

 

[Ed]

Jason Cavett skrev:

Schnip.
Okay, thanks for the explanation.

Hmm.

MVC is one of those super-powerful patterns that illuminates the
paradox of patterns themselves, namely:
- Patterns are a useful communications short-cut, distilling historical
solutions to well-known problems.
- Patterns can obscure the very problems they attempt to solve, leaving
designers concentrating more on implementing the pattern than checking
that the actual solution they are trying to solve is the same that
which the pattern was invented for. "Wood-for-the-trees."

So - for the briefest of moments - ignore the pattern and acknowledge
that what you are trying to do is encapsulate your GUI from the rest of
your software. Try to find the best way to do that, and if you end up
with MVC, then fine. If you don't, then MVC is the wrong pattern for
you.

This is probably why there are so many variations of MVC out there: one
size does not fit all.

To take a practical example, here's a poker game with an MVC variation.
The View could be web-based or Swing-based; but there will certainly be
a View. Based on this, the Model accesses the View interface directly.
It doesn't fire off events in the hope that some View is watching,
because it knows that there will always be one View (though it doesn't
care what particularl implementation the View has). Hence:
Observer-pattern unnecessary:
http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs100.html

..ed