Hi Ranchers.. What is the different between Facade & Business Delegate Pattern & Data Access Object ? They look the similiar. They add a layer in the middle, and to encapsulate sub-system to make it easier to use and protect client-app of changes in sub-system. In My opinion the different is DAO for Data Access purpose, and Business Delegate is for Bussiness logic purpose. And Facade is for General Purpose. So it means DAO & Business delegate are subset from Facade ? So DAO & Business delegate = Facade ?? Please give me a light about this problem Thank you...
A Business Delegate is a presentation/web-tier component that fronts the business API (which may well live in an EJB container). It decouples the presentation layer from the business layer. It can also reduce network traffic by caching data locally.
A Session Facade fronts the business API much like a Business Delegate but it lives in the same (EJB?) tier as the business components. A Session Facade, too, isolates the presentation layer from the business layer. It reduces network traffic because it implements high level methods, so that the presentation tier can make one single call to the Session Facade instead of dozens of little calls to the business API.
A Data Access Object is quite a different beast from the previous two. It lives deep inside the business layer and encapsulates the knowledge how a business object -- e.g. an invoice or a JavaRanch Saloon posting -- is stored -- e.g. in a database, in an XML file, or in a flat file. The idea is that when changes are made to the way things are stored -- e.g., the Saloon goes from flat files to a database -- you only have to change the DAOs. Specifically you won't have to modify the business objects themselves, where most of the complexity and risk resides. Also, you can have multiple DAOs working in tandem (using the Abstract Factory pattern), allowing you to persist the same data in a number of different ways. So a DAO is not a facade/delegate/wrapper type object at all.
Hope this helps, - Peter [ April 11, 2002: Message edited by: Peter den Haan ]