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.