It's not a secret anymore!*
The moose likes OO, Patterns, UML and Refactoring and the fly likes doubts on MVC Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "doubts on MVC " Watch "doubts on MVC " New topic
Author

doubts on MVC

Olena Golub
Ranch Hand

Joined: Jan 17, 2005
Posts: 113
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 ]

SCJP 1.4<br />SCJD 1.4 (in progress)
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Olena Golub
Ranch Hand

Joined: Jan 17, 2005
Posts: 113
Dear Ilja,
Thanks for your Answer
As I know Model View Presenter is the derivation of MVC.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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
Olena Golub
Ranch Hand

Joined: Jan 17, 2005
Posts: 113
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 ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.
 
 
subject: doubts on MVC
 
Similar Threads
Again about MVC
Decoupling the GUI
Eugene. please help in understanding your snippet on MVC
Is this MVC
doubts on MVC