In multi-layer applications, method calls for storing and reading out data are made across several layers. The business delegate pattern is used to decouple the presentation tier from the business logic . The reason for this approach is that too strong a coupling between the two layers can cause various problems.
Too strong a coupling often prevents optimal maintenance and further development of the various layers or individual components are difficult to replace. Furthermore, the presentation layer is unstable to major changes in the business layer. In this case, changes often have to be made in the presentation layer.
To avoid this, the Business Delegate design pattern is used. This hides the internal details of the implementation of the business logic (e.g. JNDI lookup, RMI , access to EJBs ) for the presentation layer . As the name delegate suggests, the access functions are encapsulated and forwarded here.
The advantage is that the presentation layer can be exchanged more easily, which is particularly useful for different clients . The Business Delegate class can also buffer results and thereby significantly improve computing performance. Likewise, very technical exceptions can be converted into exceptions that are easier for the user to understand.
If changes are made to the implementation of the business layer, it is no longer necessary to change all elements of the presentation layer, but only the business delegate classes.
In this context, there is often an additional business interface that specifies the functionalities of the business delegate classes that are available. This makes it possible to provide different implementations of the business delegate pattern.