• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Sharing across MVC

 
Greenhorn
Posts: 26
Netbeans IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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:
 
Tommy Mato
Greenhorn
Posts: 26
Netbeans IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 265
Hibernate Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic