• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Connecting the Presentation Layer to the Domain Layer

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I fairly new to OOAD so this question may sound simplistic, but I was hoping to hear from those of you with more experience in this area.
I have a fairly interactive application with many classes that interact in the domain layer. The problem is that I have to get the results of this interaction back to the presentation layer (an applet). Sets of graphic objects are acted upon and manipulated in the domain and displayed in the applet. Different buttons control different sets. I find that this generates alot of code in the event paragraphs of the applet, even if it's just to pass references back and forth.
The patterns that I'm employing are applicable to the domain layer, but there doesn't appear to be one useful for this problem.
Doesn't anyone have a better approach or a standard way of doing this?

[This message has been edited by Elizabeth Reynolds (edited July 04, 2001).]
 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The relevant patterns for your problem are:
1. Model-View Separation (aka Model-View Controller) (Bushman et al.)
2. Observer (Gamma et al.)
For a good discussion see Chapter 22 of Larman (Applying UML and Pattern) or check http://www.cetus-links.org/oo_patterns.html
Hassan
 
Elizabeth Reynolds
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Yes, I'm already attempting to apply the MVC pattern and that's where the problem lies. I have one domain class directly beneath the applet that is acting as a controller, but there is so much interaction between the domain layer and the applet that this pattern is awkward.
Observer on the other hand, doesn't appear to be applicable to this application or to this particular problem. There is no need to keep object states in sync with another at the presentation level. It is being applied to some extent in the domain level.
 
Ranch Hand
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Elizabeth,
From what I understand, the controller should delegate the work to the domain objects, rather than doing it by itself.This would avoid bloated Controllers.The Applet (view) will have visibility of the Controller(let's not call it a domain/model, since it delegates the work to domain).The applet(view) may/may not have visibilty of the domain classes(model).However, if it does,it should be through the Controller class only.
You would still require the Observer pattern, if you need to send the message from domain(model) classes to the applet(view), since the model contains the data and doesn't have direct visibility of the view.So you need to use Event handling method (an Indirection Pattern) to let the view know about the model data.
Hope this helps,
Sandeep
[This message has been edited by Desai Sandeep (edited July 05, 2001).]
 
Elizabeth Reynolds
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Desai for your comments. Perhaps I should clarify a few things. I am using the controller as you suggest. It delegates work to the "domain" objects and acts as the interface with the applet.
I am also using event handling (see first post above). In fact, that's where the interface to the controller is and no code statements really exist in the applet outside of these methods. I would hesitate to call this the Observer pattern, but I may be reading too much into the definition of this pattern.
I guess my problem is that one set of GUI objects in the applet (i.e., buttons) makes the same set of calls to the controller to get the objects manipulated in the domain layer back to the applet. The only difference, embodied in the buttons, is that before the display logic is invoked a decision is passed to the domain based on the button selected and that is what controls what takes place in the domain. This makes for a lot of redundant code in each of the event handling methods (the only difference being the decision pased), which is what I'm having a problem with it.
Is there any way to remove this redundancy from the applet event methods? (Each event results in an update to several different GUI controls in the applet, which is why there is so much code--I guess this is the observer pattern after all as applied to this set of buttons or "use case" in the applet--I was thinking across the entire applet).

On the other hand, this applet is very well behaved. I am sure this is the correct approach, but I just dislike redundant code.


[This message has been edited by Elizabeth Reynolds (edited July 05, 2001).]
 
Hassan Mumtaz
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear Elizabeth,
I may be off, but have you considered the Command Pattern?
Hassan
 
Desai Sandeep
Ranch Hand
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Elizabeth,
As Hassan has suggested, you may want to try the Command Pattern.Larman has explained this pattern in his book - Applying UML and Patterns.
I would suggest you put the same set of calls in a concrete method of the superclass and also have another abstract method which is implemented by the subclass.This method would first call the concrete method and then the class specific logic.
Does this help?
Sandeep
[This message has been edited by Desai Sandeep (edited July 06, 2001).]
 
Elizabeth Reynolds
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Not really. The calls are in the event handling methods of the applet. To generalize them to a superclass and then subtype is adding another layer on top of the controller, which seems superfluous.
 
It was the best of times. It was the worst of times. It was a tiny ad.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic