File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Object model question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Object model question" Watch "Object model question" New topic
Author

Object model question

Dave Teare
Ranch Hand

Joined: Oct 09, 2002
Posts: 80
Just a quick question: should the flight search return DataInfo objects directly to the client, or is this an internal database object that we should hide behind a "user friendly" object, such as a Flight object.
Thanks!
--Dave.
Pete Lyons
Ranch Hand

Joined: Aug 18, 2002
Posts: 109
I added a business layer that had real Flight objects. The database returned DataInfo[], but the business layer converted these to Flight objects before returning them to the UI layer. However, I know people have just used DataInfo[] everywhere and done fine. IMHO, a flight booking application with no Flight object violates some of the fundamental ideas about object modeling, encapsulation, and strong typing/programming by contract.
Dave Teare
Ranch Hand

Joined: Oct 09, 2002
Posts: 80
I tend to agree - a FlightInfo object is needed to hide the internal workings of the database. However, where would the business logic for this conversion be located?
I would normally have this logic on the server side and allow clients access to the business methods via some sort of proxy. But the requirments state that I have to implement the same DB methods for the client, and so I must have a method that returns a DataInfo object across the network. This seems to defeat the very purpose of creating a business layer.
Do I therefore make a business layer that lives on the client? Or does this just become part of the controller code the UI calls?
Thanks!
--Dave.
Pete Lyons
Ranch Hand

Joined: Aug 18, 2002
Posts: 109
I was faced with the same dillemma, and my solution was to create a business level version of the Data interface that has the same CRUD type functionality, but deals with Flights instead of DataInfos. Then I could have a local implementation or remote reference. I called this interface FlightStore. I had an additional class FlightManager that was used by the gui and encapsulated the intracacies of the booking/locking process. So I technically did not adhere to an exact implementation of all of the methods in Data, but I explained my decision carefully in the documentation, and explained how FlightStore.findFlightsMatchingQuery() was analogous to Data.criteriaFind() and so forth, and Sun did not seem to have a problem with this (I passed).
Kain
Greenhorn

Joined: Nov 07, 2002
Posts: 2
Originally posted by Pete Lyons:
I added a business layer that had real Flight objects. The database returned DataInfo[], but the business layer converted these to Flight objects before returning them to the UI layer. However, I know people have just used DataInfo[] everywhere and done fine. IMHO, a flight booking application with no Flight object violates some of the fundamental ideas about object modeling, encapsulation, and strong typing/programming by contract.

I definitely agree that information hiding and decoupling are important components of a well-designed OO system. The question is, does it really have to be a well-designed OO system? Which requirements are the most important? Is it to conform with the requested ability to search and book flights in the specified manner, or is to implement the functionality in the proposed way with data management methods exposed on the client side. My approach would most definitely be to decouple the database schema from the business logic. After all, another important aspect is to build a system that is extensible, easily understood and easily maintained.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Three things.
First, maintaining a clean separation between database, business logic, and presentation is absolutely a Good Thing[tm].
Second, this means that you have two interfaces (database <=> business logic and business logic <=> presentation). The cut between client and server can reside in either. The requirement to have a client-side component implementing the Data interface, hoewever, pushes you firmly in the direction of the former.
Third and last, note that the business layer is not reusable while the database is fully generic. Adding server capability to the database gives you far more reusability than adding it to the business layer (unless you invest a lot more development effort and reinvent EJBs).
- Peter
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Object model question