aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Who should open the data connection? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Who should open the data connection?" Watch "Who should open the data connection?" New topic
Author

Who should open the data connection?

Sam O'Neill
Ranch Hand

Joined: Nov 25, 2002
Posts: 57
Hi there
In my design I have a FlightsModel that acts as a Data Facade in that it provides a nice easy to use shell around the Data class with methods like bookFlights() and searchFlights().
At the moment my Model also has the methods openDataConnection() and closeDataConnection(), that get or close a connection to a database file respectively, because by my reckoning it is my Model that should perform these actions as it is the one that makes calls to my DBConnection object.
Am I right in this assumption or should it be the Controller's job to setup the DBConnection and then pass the acquired reference to the model which uses it?
Many thanks Sam
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

It should be the controllers job. The Facade itself is really a model.
I take the word controller as meaning the one who controls, as in everything.
Now, the way I had it work. The main method gets a Facade and passes it to the constructor of the controller along with the reference to the View.
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Sam O'Neill
Ranch Hand

Joined: Nov 25, 2002
Posts: 57
Thanks for your reply Mark
So let me verify my understanding - you passed your model/facade to the controller's constructor but the controller gets the actual Data or RemoteData instance and then passes it to the facade that makes calls to it?
Sam
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

The facade wraps around the DataAccess classes either remote or local.
Basically in your command line, I have an server address pased if in remote, or nothing if in local. It passes the args to a DataAccessFactory, the Factory then gets the corresponding object to privde data access and creates a DataAccess object. The DataAccessFacade is created and gets passed the DataAccess object to wrap around and is passed to the Controller, like I had said above. Then it's off to the races, no need to know about which type Local or Remote that you have, everything from there on out on the client works the same.

Mark
[ February 06, 2003: Message edited by: Mark Spritzler ]
Sam O'Neill
Ranch Hand

Joined: Nov 25, 2002
Posts: 57
Many thanks Mark that has certainly given me food for thought.
In my application the user has the opportunity to start in local or remote mode but then can then also change mode once the application is running by selecting the required option from a menu. I think this is overcomplicating matters unnecessarily as I can see that you start in one or the other mode and thats that which makes the choice of where to make a call to the connection factory i.e. in the application loader class an easy one.
Thanks for your input
Sam
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

Am I right in this assumption or should it be the Controller's job to setup the DBConnection and then pass the acquired reference to the model which uses it?

It is my understanding that the controller's responsibility is to listen to user actions, map them into business methods, and select views. From that, it follows that controller shouldn't do anything material in MVC. In my implementation, it is the model that is responsible for making db connections, using a data access object. Here is the code in controller where it dispatches the request to model:

... and here are the corresponding methods in the Model:

Eugene.
[ February 11, 2003: Message edited by: Eugene Kononov ]
Sam O'Neill
Ranch Hand

Joined: Nov 25, 2002
Posts: 57
Thanks that's also very helpful Eugene.
You have just made me realise that my methods that get the origins and destinations could be alot more generic to get any field in future.
Sam
Sam O'Neill
Ranch Hand

Joined: Nov 25, 2002
Posts: 57
Another question actually Eugene with regards to how you 'push' or 'pull' the data from the model to the view via your fireModelChanged() method.
I don't want to get too off the data connection topic but if I decide to 'push' my data how am I actually passing it to the view in a generic enough manner that the view never has to call any methods on the model but the model knows exactly what kind of data the view is expecting regardless of the means the view is using to display the data.
Do I need a holding Object for my origins, destinations and flights info that my view can call getter methods on? In this case is it not just as easy to pass the model and let the view call getter methods on that?
Thanks
Sam
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

that controller shouldn't do anything material in MVC

Except control it.
I mean why would they call the C in MVC the Controller if it doesn't control everything.
In my many years as a Foxpro programmer from 1996 to a couple of years ago, VFP has been OOP and has used the MVC pattern. The Controller is the one who is responsible for making the views show, and keeping track of all the views that are currently open, and when they close, and when the data changes on them, and when to make the data change.
It is the responsibility of a class, the Controller to control the MVC classes, hence it handles the calls to the Model to the View and back and forth. This is how it has always been. While you can remove that from the design and create something that is readable, it still goes against the very design of MVC.
Mark
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

The Controller is the one who is responsible for making the views show, and keeping track of all the views that are currently open, and when they close...

I agree with that...

, and when the data changes on them, and when to make the data change.

.. but I disagree with this. In my opinion, it is the Model that controls the application state (the data). And it is the View itself that should decide how to change its data. The controller should not be changing or rendering the data.
In the specific example that is discussed in this topic, I believe the responsibilties between Model, View, and Controller should be divided as follows:
Controller:
-- listens for a user action that corrsponds to a request to connect to database (i.e. a "connect to database" button click).
-- maps the user request into a business method, that is, invokes a "connectToDatabase()" on the model.
-- closes the view (if there is a separate dialog for connecting to database)
Model:
-- executes its "connectToDatabase()" method.
-- if needed, invokes its secondary methods, such as getUniqueAirports()
-- modifies the application state, (i.e changes its internal variables, such as connection object, application title, unique airports, etc.)
-- notifies all registered views about the change in the model state
View:
-- receives a notification from the Model
-- updates its GUI controls either by using the model state quiry methods (pull implementation), or by retreiving the updates from the notification message itself (push implementation).
I think this breaks down the responsibilities nicely among the components of MVC, and should be applied as such as a standard sulution to this very common problem.
That means that if I see something like the following in the controller ...
myGUI.myComboBox.setSelected(1);
myGUI.myTableModel.setModel(tableModel);
myGUI.myConnectionPanel.myRadioNetworkConnection.setSelected(true);
... I get very upset, because very minor changes in GUI require the changes in the Controller and (possibly) in the Model.
I would be the first to admit that I am no expert in MVC, so I'd love to hear from others regarding this debate (we've had it with Mark in numerous threads, but no one stepped it as a convincing authority )
Eugene
[ February 11, 2003: Message edited by: Eugene Kononov ]
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

True, I agree with everything you say except the following two statements.
-- notifies all registered views about the change in the model state
View:
-- receives a notification from the Model

I still say it is the controller that gets notified of any changes and lets the other know that it has. It still completely seperates the Model and View and Controller.
I had this in my controller and received perfect marks.

so maybe the assessor doesn't agree with your statement here
That means that if I see something like the following in the controller ...
myGUI.myComboBox.setSelected(1);
myGUI.myTableModel.setModel(tableModel);
myGUI.myConnectionPanel.myRadioNetworkConnection.setSelected(true);
... I get very upset.

Hey you changed that last sentence on me before I could quote it.
You had said that you would fail the person if you saw that code.
Mark
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

I still say it is the controller that gets notified of any changes and lets the other know that it has.

Mark,
There is a diagram on the MVC page that we have linked in this FAQ forum page (I think you recommended this page). On that diagram, there is not even an arrow from Model to Controller. I would bet you $100, my Afgan citizenship, my right to bear arms, plus my grandkids that the views get notifications from the Model, not the Controller. I am sure any other source of info on MVC will confirm it. Not to prove you wrong, but to finally settle the debate.
Eugene.
[ February 11, 2003: Message edited by: Eugene Kononov ]
Sam O'Neill
Ranch Hand

Joined: Nov 25, 2002
Posts: 57
Thanks for the debate guys, its always good stuff for novices like myself to soak up all the different points of view.
Eugene still just one question:
If you are collecting origin, destination and title information for one model update event how are you pushing all that information at once to the view?
If you are encapsulating it in a class that gets pushed and then the view calls getter methods on that class isn't this equivalent to just calling getter methods directly on the model in which case only a 'pull' is required.
I'm sorry if this is taking me a while to grasp but I am struggling with how to correctly implement the 'pull' as I don't want my view to have to know about my model except as a listener but at the same time how do I get my information to my view so that it knows how to extract what it needs?
Help much appreciated, thanks
Sam
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

If you are collecting origin, destination and title information for one model update event how are you pushing all that information at once to the view?

For the app title, and the list of origin and destination airports, I used model state query methods to update the views. That is, the model sends a simple notification such as modelChanged("dbConnectionMade"), the views receive this notification, and call the methods on the model to pull the info they need, such as "getAppTitle()" and "getDestinationAirPorts()". The disadvantage of this method, of course, is that the views must know about the model and its methods. Alternatively, you could send multiple notifications from model and include the data in this notifications. For example:
modelChanged("destinationAirports", Object data)
modelChanged("appTitle", Object data)
When the view receives this notification, it can extract the relevant data and render it.

If you are encapsulating it in a class that gets pushed and then the view calls getter methods on that class isn't this equivalent to just calling getter methods directly on the model in which case only a 'pull' is required.

The difference is that with the model "push", the views don't need to know the model or its methods. If you are pushing an object that encapsulates the update, the views still need to know the methods of this object, unless, of course, the object itself is just data.
Eugene.
Sam O'Neill
Ranch Hand

Joined: Nov 25, 2002
Posts: 57
Thanks very much for the clarification - there's a definite trade off here then: one update call but the view knows about model or multiple calls to update but view has no knowledge of model.
I will ponder on that for a while.
Sam
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

Eugene, here's my point.
Somewhere, anywhere there is application code in one of the three classes the Model, View, or controller. So when you add a button to the View, something else has to change to make that button do something. If the button is to get data, is it the responsibility of the model to know that the button was pressed and to get the data and to update the view?
Here is where I say that the controller is that class. It controls the whole enchilada. Aren't we both creating Listeners inside the controller, and doesn't it call some Action. Now I can say that this action can be in the controller or outside, that doesn't matter, because in each case one of those two classes has to change with the change of the view.
Now the view's hook methods you can put into an interface and make sure that any view you create implements the interface. As they say programming to an interface. Then if I swap out my view the controller doesn't change, it just gets a different reference.
In your design you have the Model doing some work, I say the Model just holds data and shouldn't care what to do with it, or who wants it.
Does this make sense?
Mark
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

So when you add a button to the View, something else has to change to make that button do something.

OK, but let's consider another example. Say you rename one of your GUI components, or move it from one panel to another, or replace it with something else. Now, since your controller refers to your GUI controls explicitely, it will need to change, too. But in the design that I advocate, nothing will need to change beyond the view itself.

If the button is to get data, is it the responsibility of the model to know that the button was pressed and to get the data and to update the view?

It is the reponsibility of the model to notify the views about the change in data, and it is controller's responsibility to know that the button was pressed.

Now I can say that this action can be in the controller or outside, that doesn't matter, because in each case one of those two classes has to change with the change of the view.

But it does matter, because as I demonstrated above, only a view needs to change under the 3 scenarious that I outlined. I think we need someone else to opine on the topic of our discussion, Mark, -- we just can't resolve it among the two of us.
Eugene.
[ February 12, 2003: Message edited by: Eugene Kononov ]
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

OK, but let's consider another example. Say you rename one of your GUI components, or move it from one panel to another, or replace it with something else. Now, since your controller refers to your GUI controls explicitely, it will need to change, too. But in the design that I advocate, nothing will need to change beyond the view itself.

That's what setters and getter in the view are for (JavaBean), so you can move it within the view, and not have to change the controller.
It is the reponsibility of the model to notify the views about the change in data, and it is controller's responsibility to know that the button was pressed.

So then you are saying that here the model has a reference to the view also? That sounds like more coupling.
Now isn't that two scenarios. Where was the third? I am missing that one.
Mark
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937

So then you are saying that here the model has a reference to the view also? That sounds like more coupling.

It's very weak coupling, because the Model communicates to registered Views using an Observer-Observable pattern, typically by invoking a single update() methods through the interface.

Now isn't that two scenarios. Where was the third? I am missing that one.

The three scenarios are rename GUI control, move GUI control, and replace GUI control with something else.
Eugene.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

Ah. Cool. Observable works for me.
Mark
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Who should open the data connection?