I want to implement MVC pattern for my GUI. I defined the following objects: Controller . DataModel - this represents of logical model of the data and recieves the data from the Database. The DataView - view provides all GUI-staff (buttons, text-fields, Tables etc.) I am trying to design MVC using the following structure: View <-----> Controller <------> Model
That's mean I don't want to have any direct relation between View and Model. As I understand MVC correctly I can use this structure. Am I right? I defined two listeners. One shows that Model was changed. And the second shows that View was changed. I implemented these two listeners in my Controller. My Controller knows about Model and View (has instances). And Model doesn't communicate with View directly and vice versa. The communication occurs only with the help of Controller. If the user presses some button (e.g. "Find"), View notifies the Controller that the state was changed. Controller says it to the Model (call some methods from Model) and the Model prepares data (e.g. call the Database) for find. After the data is prepared Model notifies the Controller. And Controller says it to the View (give the prepared Data from Model to View) and the View shows this Data in the table.
Do I understand and implement the MVC pattern correctly? Thanks a lot for your help! Olena [ March 30, 2005: Message edited by: Olena Golub ]
Originally posted by Olena Golub: I am trying to design MVC using the following structure: View <-----> Controller <------> Model
That's mean I don't want to have any direct relation between View and Model. As I understand MVC correctly I can use this structure. Am I right?
Not, that's definitely *not* MVC. It looks much more like Model View Presenter, which isn't bad either (and which often gets confused with MVC). You might want to google for it.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jan 17, 2005
Dear Ilja, Thanks for your Answer As I know Model View Presenter is the derivation of MVC.
MVC allows the view to depend on the model but not the other way around. A view might implement an interface required by the model and then register to be notified of data changes. The model could publish a data changed message any time something changes. You can either include the changed data on the message or require the view to turn around and ask for the changed data.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jan 17, 2005
I reimplemented it. My controller and View know about Model, but model doesn't know anything about Controller and View.
Is it correct interpretation of MVC? Regards, Olena [ March 30, 2005: Message edited by: Olena Golub ]
Joined: Jan 29, 2003
Some might quibble with who glues things together - you have the window connecting the view, model and controller while we might make a special application assembler or have the controller do it. That's not a big issue, and it's going a good direction.
This gets more interesting in larger systems. You have an interface that the model talks to and the view implements so model and view both depend on the interface. It would be good to somehow show that the model owns the interface, most likely by putting them together in a package. Then the view package clearly depends on the model package. You might substitute the word "component" for package, depending on how you build and deploy.