MVC woes

Started by
3 comments, last by Shai 18 years, 4 months ago
My problem is how I get the View to update when my Model changes. Let's say that at one point in the program the user indicates he wishes to load a file. This causes a File Dialog to appear where he selects the file. The path of this file is then stored as a string and given to the Model. The Model takes this string and opens the appropriate file. The model then reads the file and starts making new (logical) classes as commanded by the contents of the file. These classes however need to be shown on the screen. So the model has to instruct the View to start creating the appropriate graphical classes. Now the trouble I'm having is how I get the Model to communicate to the View without violating any MVC rules. As far as I can tell the Model isn't allowed to have a reference to the view.
"It's better to regret something you've done than to regret something you haven't done."
Advertisement
You should use Observer design pattern.

Your model will implements an interface IObservable.
Your view will implements an interface IObserver.

Then the view will register to the observable model (many view can do this).
When the model is modified, it just 'notify' all of its registered observers using the method 'notify(...)'.

Just google about this design pattern and it will be better explained...


have fun
Currently it is implemented using a variation on the Observer pattern. For now it works like this.

a) main() creates Model $model
b) main() creates $view by calling the constructor View($model). The model is passed as an argument. Inside the View constructor $model.registerView(this) is called to link the View to the Model. So at this point the Model has a reference to the View, but let the View do all the work.

So now Model can call all the necessary functions of the View.


I just don't know if this is the most ideal solution. As far as I can tell Observer works pretty much the same. There the model has a reference to an Observer and just calls an update() function. Here the model has a reference to the view and calls the specialized View functions.
"It's better to regret something you've done than to regret something you haven't done."
Quote:
Here the model has a reference to the view and calls the specialized View functions.


Don't do this... you're making your model know all about the view.

Quote:
the model has a reference to an Observer and just calls an update() function


The magic of the Observer pattern is just there.

The model don't know anything about any eventual views that will just display the model's content in a particular manner. But those views should know about the model through it's public interface. So when the model 'notify' the views (maybe with some messages to tell what changed more precisely...), then the views do the work by themselves by asking the model for it's changed content and display it.

I hope it clear. (sorry for my bad english...)

Look at this for more information : http://researchweb.watson.ibm.com/designpatterns/example.htm
thanks, I think I got it now :)
"It's better to regret something you've done than to regret something you haven't done."

This topic is closed to new replies.

Advertisement