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.
- Posted by: Floyd Marinescu
- Posted on: June 27 2001 23:19 EDT
Read Rules and Patterns for Session Facades.
For more information, download the Session Facade pattern from the book-in-progress: EJB Design Patterns.
- Rules and Patterns for Session Facades by Tarek Hammoud on June 28 2001 12:06 EDT
- Are design patterns widely used ? by Tochi Tochi on June 29 2001 06:03 EDT
- What about displaying an entire entity bean? by Markus Blumrich on July 02 2001 14:43 EDT
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$
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).