Hi: Many a times we find that neatly designed text book architectures being pushed by the 'client' or 'architects'. Question is how does this affect other factors such as performance, scalability etc. For example, an EJB Facade calls a Controller (Simple Java Class) that in turn calls a third party tool(through a Session Bean) for executing the business rules.(These EJB Classes are not LocalEJBs). This was argued as the best indirection in one of our projects (Facade->Controller->Rule Engine). What do you think?
One always has to be pragmatic. The moment you start to use patterns for the sake of using patterns rather than because it serves a real purpose towards making the application more robust or easier to maintain and write is the moment you should step back and take a breather. As an example of how pattern use can lead to pattern abuse, the following (note this was not a Java application but C++, the principles still hold): A large desktop application with a database and background jobs. It was decided to use a multi-layer model to build the system (though not a client-server architecture). Effectively this led to a sorta MVC-like system with a database access layer, a business logic layer and a presentation layer. All good and well, this is good design. To further decouple the layers from changes in each other layer, it was then decided to implement each layer as a multi-layer system with a service access layer, a logic layer and a presentation layer. To make decoupling even easier, it was decided that all access to objects in any other layer should be through factories only. This was then extended to have the factories themselves accessible only through "superfactories", factories whose sole purpose was the creation of other factories. So we now have a 9 layer application with 2 layers of factories in between every pair of layers. As a result the application is a perfect example of design techniques, a gem in the crown of what can be done using Rational Rose and other design tools. It's also terribly slow and impossible to debug. We had to pipe around the layers and open up holes in the architecture at several places just to have simple printjobs complete within reasonable time (read, printing 500 formletters using the proper paths through the architecture would take about 48 hours, hacking the database and printjob to work together outside the framework was required to bring that down to a more reasonable 4 hours which is still long but at least means the users can start a printrun on a separate machine in the morning and have the letters in the mail when they go home in the evening). This is the ever present danger of overengineered software, software designed by people who have not touched code ever (or at least not since graduating university), instead working ONLY with diagrams and models, then insisting their designs are followed to the letter.
I agree with you. In fact the MVC model is much abused, the model is replaced by n-layer architecture. However the example that you have given is taking incredibly long time. The infrastructure (h/w and networking) might also be culprits, i guess.
My favorite way to approach patterns is when refactoring some code I think, this is starting to look kinda like pattern X. I go to the book for pattern X and it reminds me that if I'm going to wargle a brup, I _might_ need a framifier. If the fit is good enough, I might rename some classes to help future readers recognize the pattern more quickly. Patterns give me value, but I don't go to the book looking for one to implement next.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I think what Stan describes is an approach taken by many skilled patter-users. The trouble is that for it to work well, the practitioner needs to have at least a rough knowledge of some sort of pattern catalogue, in order to recognise incipient patterns. Most abuses of patterns seem to originate from developers who are only familiar with a very small set of patterns. Iin the all-too-common example, a developer who has heard of Singleton, and is determined to use it in the next project The difficulty seems to be how to most effectively get a broad, if shallow, knowledge of patterns across to new or inexperienced developers, so that the "grown up" approach of refactoring to patterns when appropriate seems a natural way to work.