File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Connecting the Presentation Layer to the Domain Layer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Connecting the Presentation Layer to the Domain Layer" Watch "Connecting the Presentation Layer to the Domain Layer" New topic
Author

Connecting the Presentation Layer to the Domain Layer

Elizabeth Reynolds
Greenhorn

Joined: Jun 16, 2001
Posts: 12
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).]
Hassan Mumtaz
Greenhorn

Joined: Jul 04, 2001
Posts: 15
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

Joined: Jun 16, 2001
Posts: 12

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.
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
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

Joined: Jun 16, 2001
Posts: 12
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

Joined: Jul 04, 2001
Posts: 15
Dear Elizabeth,
I may be off, but have you considered the Command Pattern?
Hassan
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
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

Joined: Jun 16, 2001
Posts: 12

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Connecting the Presentation Layer to the Domain Layer