J2EE Development Frameworks
Java 2 Enterprise Edition has excelled at standardizing many important middleware concepts. For example, J2EE provides a standard interface for distributed transaction management, directory services, and messaging. In addition, Java 2 Standard Edition(J2SE),which underpins J2EE,provides a largely successful standard for Java interaction with relational databases.
However, as the”J2EE’s Lack of Application Programming Support”sidebar explains, the platform has failed to deliver a satisfactory application programming model.
Sun Microsystems and the large application server vendors have traditionally responded to this problem by advocating development tools as a way to hide J2EE’s complexity. However, tools for managing J2EE artifacts aren’t nearly as good as tools for working with the Java language, with their sophisticated refactoring capabilities, and J2EE tool support is generally inferior to that of the  platform. Many J2EE tools are themselves complex, as is the code they generate.
Many in the open source community, especially smaller vendors, have chosen the alternative of developing frameworks designed to simplify the experience of building J2EE applications. Popular frameworks such as Struts, Hibernate, and the Spring Framework play an important role in many of toda
y’s J2EE development projects.
WHY USE A FRAMEWORK
A software framework is a set of classes that make up a reusable design for an application or, more commonly, one tier of an application. Whereas application code and thus manages the flow of control. This is often referred to as the Hollywood principle:” Don’t call us, we’ll call you.”The application developer writes code that the framework will then call at runtime.
Designing a framework for use in a wide variety of unknown contexts is challenging. However, the framework approach is well adapted to the complexities of J2EE development because it can provide a simple, easy-to-use model for application programmers.
Using a well-designed open source framework offers many advantages: * With a good framework, developers write only the code they need to write; They don’t get bogged down working directly with low infrastructure APIs. This is the key value proposition.
* A well-designed framework can provide structure and consistency to an application. The structure will be clear to additional developers joining the project.
* An easy-to-follow framework can promote best practice through examples and documentation.
* Successful open source frameworks are better tested than in house code. * Frameworks usually become popular only if they have something to offer. In-house frameworks are often mandated, while a J2EE project is likely to adopt an open source framework only if it delivers clear benefits.
J2EE itself defines several frameworks. For example, an Enterprise JavaBeans(EJB) container or Servlet engine relies on the Hollywood principle, with the J2EE runtime instantiating and invoking managed objects. Open source Web application frameworks such as Struts add their own framework over the standard Servlet framework. The emphasis is on frameworks above J2EE, which provide a simpler programming model or other benefits.
OPEN SOURCE FRAMEWORKS EMERGE
Most large J2EE projects have traditionally used in house frameworks to hide the platform’s complexity. Only recently has a consensus emerged
about the generic problems that provide good generic solutions. There is now a clear trend for frameworks to “standardize”more of the infrastructure that formerly was developed on a per-project basis.
One reason for J2EE frameworks’ sudden popularity is the platform’s increased maturity. Developers now recognize areas in which the standard APIs are deficient and know from experience how difficult it is to write a good framework to fill the gap. In addition, many high-quality frameworks are now available that offer outstanding documentation and the support of a focused development team, without imposing licensing fees.
Struts
The trend toward open source frameworks began with Web applications. In 1999-2000, developers realized the deficiencies of the java Server Pages”Model 1”approach, in which JSP templates handled incoming requests as well as static template data. This meant that JSP often contained both business logic and complex HTML or other markup.
With no standard framework in place J2EE specification support, developers responded with their own Front Controller implementations. These moved business logic to Java classes, thereby eliminating the need to maintain such hybrid artifacts.
The Front Controller pattern is often referred to as Web MVC after the classic Model View Controller architecture pattern that is common to GUI development in object-oriented languages. (The name is so
mewhat misleading in that Web MVC views must pull information from the model, whereas in classic MVC, the model pushes events to views.)
Initial Front Controller implementations varied greatly in quality. The Apache Software Foundation’s release of Struts in 2001-2002 changed all this. While not an ideal Web MVC framework, Struts worked well enough to quickly become the de facto standard.
Struts demonstrated all the benefits of open source frameworks such
as ease of recruiting personnel familiar with the structure it imposed. By late 2002, it was the natural choice for most J2EE Web applications, and every serious J2EE Web developer was familiar with it.
The near-universal adoption of Struts commoditized an important chunk of the J2EE architectural stack. Even conservative organizations accepted its use in a prominent part of their software infrastructure and agreed to the Apache license’s terns.
Hibernate
The next domino to fall was persistence. J2EE “out of the box”provided two means for accessing persistent stores-most often, relational database: JDBC, the J2SE standard API for relational database
management system access; and entity beans, an EJB component type dedicated to modeling a persistent entity.spring framework是什么框架的
JDBC is error-prone programming model inhibited object-oriented design by forcing developers to work with relational concepts in Java code. Entity beans, despite hype from Sun and major J2EE vendors, likewise proved to be cumbersome: Initially, the technology was severely underspecified, not even taking into account management of relationships between persistent objects; it made applications difficult to test; and it offered an inadequate query language. By 2003, developers largely ignored entity beans despite enhancements in EJB  and .
Early efforts
Solutions to the persistence problem came in the form of object-relational mapping, which provides transparent persistence for plain old Java objects, a concept described in the sidebar, “The Noninvasive Framework: Power to the POJO.”Though not unique to Java, ORM is especially popular in the Java community-compared, for example, to .NET developers, who seem to regard it with suspicion.
Commercial ORM tools such as Oracle’s TopLink were well established by the late1990s, but only a mi
nority of projects used them because they were expensive, complex, and appeared to conflict with the Sun-sanctioned entity bean standard. Nevertheless, they usually achieved better results in practice than JDBC or entity beans, thus proving the case for POJO persistence.
Java Data Objects, which appeared as a Java Community Process specification in 2001, offered generic POJO persistence to any persistent store (although implementations typically provided their best support for relational database). However, Sun’s lukewarm attitude toward JDO, coupled with J2EE vendors’ lack of interest in POJO persistence at that time, prevented the technology from achieving popularity.
Hibernate arrives
Radical change came in 2002 for two reasons. First was widespread realization that entity beans had failed in practice, and that developers should ignore that part of J2EE specifications. By retarding rather than advancing the progress of ORM in Java, entity beans remain a prime example of how poor specifications can stifle development of superior technologies.
The second factor was the arrival of Hibernate, the first popular, fully featured open source ORM solution. Hibernate offered fewer features than TopLink but delivered a robust implementation of the m
ost desirable ones, and its focused development team aggressively sought improvements. Hibernate wasn’t particularly innovative, building on the extensive understanding of ORM, but it offered a more intuitive programming model than existing competitors and removed at one stroke cost and ease-of-use barriers to ORM.
Around the same time, new commercial products offered highly efficient implementations of the JDO specification that targeted relational

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。