This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Java in General and the fly likes Sharing across 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 » Java » Java in General
Bookmark "Sharing across MVC" Watch "Sharing across MVC" New topic
Author

Sharing across MVC

Tommy Mato
Greenhorn

Joined: Dec 14, 2007
Posts: 26

I'm writing a program to collect and display currency prices. This is my first attempt at developing to the Model-View-Controller design pattern.

My question: how to design the structure of the program so that common objects and design elements are available to the model, the view and the controller.

For example, I want to create a 'properties' object that will contain all of the properties of my program. Some of these properties will be accessed by the model code, some by the view and some by the controller.

Isn't having a single properties file/object breaking the independance of the M V and C? Should I think about having 3 separate properties files? After all, if I want to replace the View with another completly different view, I shouldn't have to 'disentangle' my view properties from the M and C properties.

If I can get away with having one file/object, how should I pass this object to the M, V and C? Is there a 'central' object that acts as the 'conductor' to the M V and C?

I would imagine that this is a common problem that applies to other objects that should be shared between the MVC components.

I hope this makes sense. Solutions and advice will be gratefully received. Thank you in advance.
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
Originally posted by Tommy Mato:
Isn't having a single properties file/object breaking the independance of the M V and C? Should I think about having 3 separate properties files? After all, if I want to replace the View with another completly different view, I shouldn't have to 'disentangle' my view properties from the M and C properties.


No, exactly the opposite.

If I can get away with having one file/object, how should I pass this object to the M, V and C? Is there a 'central' object that acts as the 'conductor' to the M V and C?


The 'central' object is the controller. Think of it for now as "Program starts here." Then build a data model by considering what data or methods your program needs. Consider how to read or 'get' the data. That may be the view.

I would imagine that this is a common problem that applies to other objects that should be shared between the MVC components.


Can you identifiy those objects, and describe them to us or show sample code with which the program would need to share data?

I hope this makes sense. Solutions and advice will be gratefully received.


Sounds good so far:


"The differential equations that describe dynamic interactions of power generators are similar to that of the gravitational interplay among celestial bodies, which is chaotic in nature."
Tommy Mato
Greenhorn

Joined: Dec 14, 2007
Posts: 26

Many thanks for your response. I found it valuable when you stated that the controller is the 'conductor' and 'your program starts here'. That made the pieces of my understanding fall into place.

Another object that I will be sharing is a trading calendar - which specifies dates and times when the various exchanges (NY, Tokyo, London) are closed. That information will be shared by the Model and the View.

From what you are saying, it sounds like I should create the properties object and the trading_calendar object in the controller and then pass them to the model and the view at creation.

In sequence:
1. Create Controller
2. Controller creates Properties object (P)
3. Controller creates Calendar object (C)
4. Controller creates Model (and passes P and C)
5. Controller creates View (and passes P and C)

Thanks again.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
The Model is the main component of a MVC-based application. Here is where the business requirements are implemented. The Controller is only responsible for coordinating and mediating between the View and Model.

Controller should not be responsible for handling global configuration properties. The purpose of the Controller component is to mediate between the View components and the Model. For example, a user enters some text and clicks a submit button. The code of the Controller connects with Model and sends data and something indicating what action to perform. After the Model does whatever it does, it sends a response to the code of the Controller. The Controller sends a response back to the View. The Controller does not contain any code or logic for executing whatever behavior should occur when a user submits data.

A key indicator of whether your design adheres to the MVC pattern is that you should be able to execute the application without a Controller and a View, e.g. from a command line via main method. If you cannot execute the application methods from a command-line main method, then you don't have an independent Model application.

Global configuration properties are easily stored in a Java class.



Struts (http://struts.apache.org/) - An open source framework for building Servlet/JSP based web applications based on the Model-View-Controller (MVC) design pattern.
[ April 25, 2008: Message edited by: James Clark ]
Stevi Deter
Ranch Hand

Joined: Mar 22, 2008
Posts: 265

Tommy,

It sounds like the calendar is in fact part of your model. You encapsulate business rules like "when is this exchange open" in your model.

Then the view asks the Controller for details, which the Controller gets from the model.

For example, your controller tier may have a service method isExchangeOpen(Exchange). The View can then ask the Controller for this information. It doesn't care how the Controller determines it.

You can then decide for the View level "can i show this view at all if the exchange is closed", etc. which lets you separate your display logic from your business logic.
[ April 25, 2008: Message edited by: Stevi Deter ]

There will always be people who are ahead of the curve, and people who are behind the curve. But knowledge moves the curve. --Bill James
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Sharing across MVC
 
Similar Threads
Sharing across MVC
Design patterns used in Swing and RMI API
MVC question - where's the model?
More Model-View-Controller advice needed
good old(!) MVC