Business Objects represent too much information or behavior to transfer to remote client
Client may get information they don't need
Client may get information they can't handle
Client may get information they are not authorized to use
Client may get too much information/behavior to be useful (e.g., entire database serialized to client)
Some clients are local and can share object references with business logic
Handling specifics of remote clients outside of core scope of business logic
Layer a Remote Facade over Business Logic
Remote Facade constructs Data Transfer Objects (DTOs) from Business Objects that are appropriate for remote client view
Remote Facade uses DTOs to construct or locate Business Objects to communicate with Business Logic
Data Transfer ObjectRepresents a subset of the state of the application at a point in time
Not dependent on Business Objects or server-side technologies
Doing so would require sending Business Objects to client
XML and JSON provide the “ultimate isolation” in DTO implementation/isolation
Remote FacadeUses Business Logic to perform core business logic
Layered on top of Business Logic to translate between Business Objects and DTOs
Business LogicContinues to perform core duties as described in DAO Pattern
Business Object (Entity)Continues to perform core duties as described in DAO Pattern
May have more server-side-specific logic when DTOs are present in the design
Clients only get what they need
Clients only get what they understand
Clients only get what they are authorized to use
Remote and Local interfaces to services are different
Makes it harder to provide location transparency
Lightweight Business Objects can be used as DTOs
Remote Facade must make sure they are “pruned” of excess related items before transferring to client
Remote Facade must make sure they are “cleaned” of DAO persistence classes before transferring to client