A brief history of development framework of Java EE

Java EE JAVA2 Enterprise Edition has played a very important role in the unification of the middleware domain idea. For example, Java EE provides a standard set of programming interfaces for distributed transaction management, directory services, and messaging services. Java EE's basic--JAVA2 Standard Edition (J2SE) has successfully provided a set of standards to access relational databases.

However, as mentioned in the article "Java EE lacks support for programming," the Java EE platform does not provide a satisfactory application programming model (application programming models). Sun and some of the big application server vendors want to use development tools to reduce the complexity of Java EE development, but these tools are not as good as others, the latter have advanced refactoring tools, compared to the. NET platform, Java EE tool support is inferior.

Many Java EE development tools automatically generate code that is as complex as the tools themselves. In the open source community, many small Java EE developers have chosen another way of development--some development frameworks that can reduce the difficulty of Java development, such as Struts, Hibernate, and the Spring framework, They play an important role in many of today's Java projects.

　　 Why should we adopt a framework?

A framework is made up of classes that formally provide the application with a reusable design-or, as we've often mentioned, a layer of application species. The application code accesses the class library to perform tasks, and the framework calls the application code to manage the process of the program. This is the usual Hollywood rule: "Don't try to contact us, we'll let you know by then." "Developer-written programs are called by the framework at run time.

It is challenging to design a framework that can be used in a variety of unknown contexts. The framework is ideal for use in complex Java EE Development, which can provide a simple and easy-to-use model for developers. There are many benefits to adopting a well-designed open source framework:

• In a good frame, developers just need to write some of the necessary code; they don't need direct access to the underlying APIs. This is important.

• A well-designed framework can provide a clear structure for the program and increase the cohesion of the program. A clear structure makes it easier for others to join the project.

• An easy-to-use framework can provide users with best practices through a number of examples and documentation.

• Code that uses a successful framework is easier to test than your own code

• Frameworks can become popular only if they provide some of the features that are worth using. The Java EE project only uses it when it really needs a framework, and its own framework is not the case, the latter is in the dominant position.

The Java EE itself also provides some framework. For example, Enterprise Java-beans (EJB) container or Servlet engine, both use the idea of "using the Hollywood Principle," and use Run-time calls to manage objects. Like struts these open source Web application frameworks are formally built on these two frameworks, and the focus of this article is on the framework built on Java EE like struts, which provides developers with simpler models and other benefits.

　　 the emergence of open source framework

Many large Java EE projects use their own internal framework to hide the complexity of the platform, until recently people have gradually found some common problems in many projects, these problems can be solved by a more unified solution. And some frameworks can act as solutions to these problems. There is a clear trend now: These frameworks will become a more "standardized" solution to these challenges than the previous internal frameworks.

The growing sophistication of the Java-EE platform is one reason for the popularity of these frameworks. Developers know that there are some places where the standard API is powerless, and it's hard to make up for it in terms of their experience. At the same time, some excellent open source frameworks are available, they provide extremely rich technical documentation, there is a professional support behind them, and everything is free.

Struts, the open source framework when Web applications are generated. In the 1999-2000, developers realised the pitfalls of JSP "Model1", where JSP was flooded with request-processing code and static data templates, which meant you had to mix business logic with complex HTML and other tags. At that time there is no standard framework and Java standard support, to solve this problem developers have to implement their own front-end controller, so that the business logic can be separated into Java classes, which can reduce the difficulty of maintaining JSP. The front-end controller pattern is often used in the MVC architecture, and the MVC pattern is often employed in OO-language GUI development (the name is always misleading, and the view in WEB MVC is "pulling" data from the model; in classic MVC, the Model "pushes" the event into view).

The initial front-end controller achieved uneven quality. 2001-2002 years, the Apache open source organization released struts to change this situation, although it is not a perfect framework, but it is enough to make it a de facto standard in this field.

Struts has shown some of the advantages of the open source framework, for example, that novices can easily familiarize themselves with its structure. At the end of 2002, it set up a lot of Java project is a natural choice, every serious Java EE developers will be familiar with it.

Struts uses almost every Java-EE project, which makes it an important part of the Java EE architecture. Even many conservative organizations use it as part of the bottom of the software and agree to accept the terms of the Apache open source agreement.

Hibernate. The next Naomi of a fallen bony card is permanence. Java EE provides two means of persistence: JDBC, which is the standard API for accessing relational database systems in J2SE, and the other is the entity beans, which is the component of the EJB that specializes in modeling persistent entities.

JDBC uses a wrong programming model to force developers to handle relational ideas with Java code. and entity beans, not to mention the boast of sun and other major Java EE vendors, gives a clunky feeling: At first the application of the technology was so narrow that the relationship between the persistent objects could not be dealt with. It makes the application difficult to test and uses a bad query language. Until 2003, even though EJB2.0 and 2.0 made a lot of improvements, developers rarely used it.

　　 an early attempt

The solution to the persistence problem is resolved by relational-object mapping (ORM), which transparently persists the normal Java object (POJO). The idea is explained in the annotation. Although this scenario is not proprietary Java. But compared with other communities such as. Net,orm is more prevalent in the Java community (. NET developers always have a skeptical attitude.

As early as 1990, some commercial ORM tools appeared, such as TopLink. But because of its expensive, complex structure and conflicting with Sun's entity bean standards, few people use it. However, in terms of persistent pojo, these tools do make a lot of progress compared to JDBC and entity beans

Java Data object appears in the specification of the Java Community Progress (www.jcp.org) in 2001. It provides most of the persistence implementations for general Pojo (although many implementations are for relational databases). But Sun and other Java EE technology providers have been very cool with the technology. So JDO has not been able to be popular either.

The appearance of Hibernate. The ORM field changed a lot in 2002, for two reasons. First, the entity beans failed in practice, and the developers ignored it from the Java EE. It shows developers how a specification is going to drag development into the mire.

Another reason is the release of Hibernate, which is the first functional solution for solving relational object mapping. Although functionally, it is not toplink and diverse. But on the most common features, Hibernate is more robust and has a very professional team that provides full time development. Hibernate is not entirely new, its ORM is common in this field, but it provides a programming model that is easier to use than any competitor, and it provides an easier, cheaper way to use ORM.

At the same time, a new generation of commercial products provides an extremely efficient implementation of the JDO specification for relational databases. This makes the developer's choice richer, and TopLink is also moving in a developer-friendly direction, and its liscense is increasingly open.

　　 ORM Swept

All of these factors are ORM more canonical than ever. While many projects still use their own persistence layer framework, Hibernate,toplink and some high-end JDO implementations make it harder and less maintainable to use your own persistence layer framework, and there's no reason to use your own framework.

Although the functional coverage of these frameworks is already very large, there are still a lot of places out there. For example, a struts,hibernate based project, the business logic is difficult to handle. Although the Java EE specification presents a solution (EJB) For this problem, there is still no suitable programming model.

　　 Spring

The Java EE framework is applied to projects on a large scale, and projects are always responsible for connecting these frameworks and their own business code to make them truly integrated. Spring is focused on this problem, and it blends well with hibernate.

Spring is essentially a combination of the IOC (inversion of control) and aspect-oriented programming (AOP). It is a non-invasive framework that enhances the functionality of the Pojo. From the services (with a service abstraction), it decoupled the program code from the Java EE environment to a normal java-based object (naturally, this code can be run in a variety of environments out of Java EE). It also provides options for many functions other than EJBS-for example, to provide declarative transactions for all Pojo. Spring is widely used in many projects, from small web programs to large enterprise applications.

There are other products in this field, such as Hivemind and Namocontainer. The former is about the same as spring, but there is a big difference in the IOC, which blends many services into the Picocontainer IOC container. The difference between the way these products are implemented and the Java EE is that they are very lightweight.

It is very difficult to do tests under the Java EE API, which pojo from the Java EE API, thus greatly reducing the difficulty of the test. Test A common Java object, not like testing Java program, you have to first deploy the application to the server, or you have to simulate the environment. Providing an increasingly popular test-driven development environment (which is due for developers) is a key factor in the popularity of these lightweight containers.

　　 who's going to be next?

The increasing emphasis on open source frameworks has led to a significant reduction in the cost of many projects and increased use and maintenance. Now the open source framework has a high quality, providing good documentation and some books for developers to refer to. Even so, the two factors are fraught with uncertainty: the conflict between open source and the "standard" of Java, and the growing importance of AOP.

The conflict between open source and standard is manifested in two places. One is the performance layer, and there are sun companies and other big companies behind JSF, and in this area there are competing open source products such as struts. In the middle tier, EJB 3.0 implements Dependency injection (dependency injection) with j2se5.0 annotations, but this feature is only a subset of spring

In these two areas, open source products are more innovative. JSP borrowed the ASP.net, and tapestry adopted the idea of WebObjects.

Similarly, it is not known why EJB3.0 is trying to standardize dependency injection, even if it inevitably loses many functions. EJB 3.0 seems to go into the programming world as well, and the Java EE specification has not yet been involved.

At the same time, the importance of AOP in the Java community soared, in the use of AOP is increasingly favored by developers. The "AOP with crutches" implementation, such as spring and DYNAOP, has elevated the profile of AOP. and pure AOP technology such as ASPECTJ, will be popular in the years ahead.

Second, JBoss is consistent through JCP and EJB3.0, which greatly promotes AOP technology. But even so, JCP has not turned to an AOP sign.

The next generation of Java EE specifications will embrace a simpler Pojo programming model, just as spring and hibernate do. Java EE developers are also destined to go from "fraudulent customers" to their own programming experience to develop. This change will be welcomed by most people, unlike before every new specification is released, and ultimately it is not implemented well.