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.
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.
Joined: Oct 09, 2002
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.
Joined: Aug 18, 2002
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).
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.
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