Many common problems (beyond those addressed by J2EE application servers) have beensolved well by open source or commercial packages and frameworks. In such cases, designing and implementing a proprietary solution may be wasted effort. By adopting an existing solution,we are free to devote all our effort to meeting business requirements.
After commenting that existing frameworks can mean a slightly steeper learning curve, Rod later motivates why this trade-off isworthwhile to gain a strong application infrastructure. On page 395, he clearly explains the benefits:
Using a strong standard infrastructure can deliver better applications, faster. A strong infrastructure makes this possible by achieving the following goals:
Allowing application code to concentrate on implementing business logic and other application functionality with a minimum of distraction. This reduces time to market by reducing development effort, and reduces costs throughout the project lifecycle by making application code more maintainable (because it is simpler and focused on the problem domain). This is the ultimate goal, which many of the following goals help us toachieve.
Separating configuration from Java code
Facilitating the use of OO design by eliminating the need for common compromises.
Eliminating code duplication, by solving each problem only once. Once we have a good solution for a problem such as a complex API we should always use that solution, inwhatever components or classes that encounter the problem
Concealing the complexity of J2EE APIs. We've already seen this with JDBC; other APIs that are candidate for a higher-level of abstraction include JNDI and EJB access
Ensuring correct error handling. We saw the importance of this when working withJDBC in Chapter 9.
Facilitating internationalization if required.
Enhancing productivity without compromising architectural principles. Without adequateinfrastructure, it is tempting to cut corners by adopting quick, hacky solutions that will cause ongoing problems. Appropriate infrastructure should encourage and facilitate theapplication of sound design principles.
Achieving consistency between applications within an organization. If all applicationsuse the same infrastructure as well as the same application server and underlying technologies, productivity will be maximized, teamwork more effective, and risk reduced.
Ensuring that applications are easy to test. Where possible, a framework should allow application code to be tested without deployment on an application server.
Several existing application frameworks provide ready-to-use implementations of the kind of strong application infrastructure thatRod recommends. If you use
frameworks, you won't have to design, code, debug, and maintain your own infrastructurecode.In this whitepaper, we examine two existing J2EE frameworks by studying a working sample application. By patterning thesample application after the "classic" Java Pet Store Demo, we've made it easier for readers familiar with the original demo tocompare the developer productivity that a framework-based J2EE development approach can provide.
Rebuilding a Web Storefront with Struts and ADF
The ADF Toy Store demo is a simple web storefront application adhering to the Model/View/Controller (MVC) design pattern. Itis implemented using two existing J2EE application frameworks: Apache Struts