The Session Facade pattern is probably the most common design pattern used in EJB architectures. It optimizes systems by executing complex use cases in one network call, and also enforces a clear and strict separation of business logic from presentation and data logic. A new article by Kyle Brown explains the pattern and its intricacies.

Read Rules and Patterns for Session Facades.
For more information, download the Session Facade pattern from the book-in-progress: EJB Design Patterns.

What a fantastic document. Thank you.

... given the current state of the software industry, I doubt it. There does not seem to be the notion of using design patterns in the software industry especially the dominant Microsoft realm.

General construction based engineers use well known patterns to do their job - its a shame we cannot say the same for our industry. No wonder bridges and rail roads never crash but software increasingly SUCKS !

It depends on the company's culture & project initiative. The bank i am working with has a bias using design patterns cuz it's new to them just like J2EE. And some artchitects argues with overheads (more method calls) in patterns. But no one here on top seems to understand how a good pattern & framework helps the business to save $$$ in the longer term.

Another problem is the skill level in the full time staff. Most of people in bank's I.T are trained in non engineered way but more customed to VB style programming, i.e. everything visual & 1000 lines procedural codes.

I would expect the usage of design pattern pushed by the real professionals in Corporate America.

just my 0.02$
Victor

I like this article a lot... it clearly articulates many of the ideas I have been trying to communicate to colleages. I'm not in favor of having shadow objects essentially the same size as the entity beans themselves (I think the author calls them "bulk accessors") - but what other possible way would there be to represent all the information stored within a bean. I mean if you wanted to edit an account, for example, which was an entity bean - how would you get its information to the user interface (and back again!) without constructing such a shadow object. Shadow objects just seem wastefull to me since you already have an object which represents the entity (with your remote entity bean object).