We know the "Flight" class in the bussiness domain model, but it can't represent origin flight data. It means the flight of prepared itinerary. Am I right? Then my question is that should we design the origin flight data or just design a DAO class to wrap all the bussiness logic?
Please share your opinion Thanks.
Best Regards<br /> <br />SCJP1.4 SCJD1.4 SCEA
Joined: Apr 01, 2002
In general, business logic inside a DAO is not recommended approach. A Data Access Object is meant to manipulate database access in a separate layer. I suggest you to look into DataAccessObject pattern at :
Thanks for your reply. I did say something wrong, but I mean that we might wrap the origin flight data in a SLSB with a DAO. But could anybody answer my question?
Joined: Aug 01, 2000
IMO, the Filght and associated business domain classes can be used for two purpose: one for Itenerary, one for flight catalog. Admin provides new filghts to the the catalog. Cuctomers search the flights in the catalog using DAO and may have some kind of cache, but book a flight using entity beans(updating happens on both Itenerary and catalog side). after a flight taking off or any other reason to be unavaible, a status flag changed and the data becomes historic.