• 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

Object model question

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

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.
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
reply
    Bookmark Topic Watch Topic
  • New Topic