Business delegate pattern doubt
Hi,
One of the reasons for going for Business delegate pattern is because the business components is vulnerable to changes.
Suppose if the business component has a method
getAccountInfo( int Accountnumber)
The business delegate pattern may have a method
getAccountInfoFromBusiness(Accountnumber int)
{
return businesscomponent.getAccountInfo(Accountnumber);
}
and the presentation tier components will have code containing invoking to getAccountInfoFromBusiness method.
Now suppose if business component method signature changes then the signature of business delegate class will also change. This turn in requires changes to presentation tier components. I really dont understand why business delegate pattern is needed.
[789 byte] By [
mpbhata] at [2007-9-27 12:44:32]
> Hi,
>
> One of the reasons for going for Business delegate
> pattern is because the business components is
> vulnerable to changes.
Abstraction is your first tool to reduce a projects exposure to change.
Secondly filling you code with getter and setters is a bad idea, it's procedural not OO, Objects should express themselves.
So instead of :
> Suppose if the business component has a method
>getAccountInfo( int Accountnumber)
consider
Account account = getAccount( AccountID accountID ) ;// or
Account account = findAccount( AccountName accountName ) ;
... AccountInfo = account.toString( FULL ) ;// or
... AccountSummary = account.toString( SUMMARY ) ;// or
... AccountBalance = account.balance() ;
This abstracts the Account's identification, from an int, makes your code robust to change, and more flexible, and easier to understand.
> The business delegate pattern may have a method
This is not good, the naming is particularly specific and relies on assumptions about the architecture, it looks like a a global function, yet should be a method of businesscomponent, which is also badly named.
>getAccountInfoFromBusiness(Accountnumber int)
>{
>return businesscomponent.getAccountInfo(Accountnumber);
>}
Instead consider the following. I've used abstraction to hide the implementation details, and the relations model real life, and I can handle my objects polymorphically.
class Account { ... }
class DayBook {
Hashtable accounts ;
public Account getAccount( AccountID accountID )
{
accounts.get( AccountID accountID )
}
class MyApp
{
DayBook salesDayBook = new DayBook() ;
DayBook purchaseDayBook = new DayBook() ;
Account account = salesDayBook.getAccount( theAccID ) ;
Account account = purchaseDayBook.getAccount( theAccID ) ;
}
Here DayBook is a collection of Accounts, I've two instances, one for my sales one for my purchases.
> and the presentation tier components will have code
> containing invoking to getAccountInfoFromBusiness
> method.
>
> Now suppose if business component method signature
> changes then the signature of business delegate class
> will also change. This turn in requires changes to
> presentation tier components. I really dont understand
> why business delegate pattern is needed.
The Business Delegate is not really a pattern as such, it is an appliction of the Proxy pattern abstracted into Business language/terminology.
