What are the advantages and disadvantages of the Session Façade Core J2EE Pattern?
What are the assumptions behind it?
Are these assumptions valid in a particular environment?
Disadvantages of the SessionFacade pattern: it assumes a specific enterprise architecture that is constrained by the limits of the J2EE 1.4 specification (see Rod Johnson's books for these criticisms). The most damaging disadvantage is that it is more complicated than necessary.
The Facade pattern offers the following benefits: It shields clients from subsystem components, thereby reducing the number of objects that clients deal with and making the subsystem easier to use. It promotes weak coupling between the subsystem and its clients. Often the components in a subsystem are strongly coupled.
The Session Facade is a coarse-grained object that allows encapsulation of the workflow by managing business data and business service objects interactions. Business data objects can be entity beans or DAOs, and the business service objects can be session beans and other objects that provide service.
Session Facade is a fantastic pattern - it is really a specific version of the Business Facade pattern. The idea is to tie up business functionality into discrete bundles - such as TransferMoney(), Withdraw(), Deposit()... So that your UI code is accessing things in terms of business operations instead of low level data access or other details that it shouldn't have to be concerned with.
Specifically with the Session Facade - you use a Session EJB to act as the business facade - which is nice cause then you can take advantage of all the J2EE services (authentication/authorization, transactions, etc)...
Hope that helps...
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With