Three advantages of using EJB development

The Java language has slowly become one of the mainstream development languages, or it has become the mainstream development language. On the Java language platform, a variety of development models have emerged. For a novice Java programmer, perhaps the face of so many development models, will be dazzled, do not know how to choose. When I first started to touch the Java language, I didn't have much development model to choose from. And in the past few years I have encountered this problem. The optional development model is more, the author must choose a development model as the main direction of their future. Because people's energy is limited, especially we do program development. We must devote our limited energies to the cutting edge. The author recommends the EJB development model here.

This EJB is essentially a managed component that exists in the Java EE container and is created, controlled, and destroyed by the Java EE container. The Java EE container is complex to control the number of EJBS currently in existence and the resources used by the EJB. In the case of heavy load, even the EJB that the client is using will be returned to the instance pool, so that the EJB instance can be used by other clients to improve the utilization of the EJB instance. Although the official Java EE is also recommended to use EJB, but this is not a mandatory measure. In addition to leveraging EJBS, program developers can also take advantage of JSP or stand-alone Java applications, and so on. However, if the application needs constant upgrades, high performance requirements, and so on, then I recommend to everyone to use EJB, there are mainly the following three reasons.

One, you can hide the pipe code.

Now the music fountain has been adopted rapidly everywhere, becoming a representative of the High-tech landscape. Programmers need to use these pipes when they develop the application, but they don't need to know the exact direction of the plumbing. This is not something that developers of the program need to focus on. Program developers need to use these out-of-the-box pipelines directly. We call these pipes "pipe codes." In fact, program developers are sometimes like an industrial designer. Industrial designers do not have to care about water pipes when they design a shower faucet. Why? Because the water pipe is the same standard, the pressure of the state has a mandatory standard. To do this, the designer needs to refer directly to these standardized parameters when using pipelines. In some early development models, such as the most primitive CORBA development model, the program developers had to write a lot of code to complete the interaction, connection and registration process with CORBA environment. In fact, these codes are commonly referred to as pipe code. If you use an EJB model, you can minimize the coding of these piping codes.

A program developer can specify the transactional nature of a component without having to write code to control the functionality by declaring the property, without having to write piping code to define the relationship between the EJB components and the resources that are needed. Because a deployable Java EE application defines the relationship between multiple EJB components in the deployment description, it also defines the resources that the EJB component needs to use; If each bean follows a defined declaration cycle and a set of rules, the program developer does not need to know the "piping" design, And only need to know the parameters of the pipeline interface, so the system code and application code is two separate content.

Obviously, the EJB component provided by Java EE allows the program developer to focus on the writing of business code and minimize the writing of piping code. This can not only improve the development efficiency of the application, but also separate the pipeline code from the application code, and facilitate the subsequent debugging and maintenance. This is the first reason I recommend using the EJB model to develop Java applications.

Two, EJB predefined some complex processing mechanism.

In the process of application development, there is more or less common content. If you need to perform lifecycle management for your application, you need to name and register, you need transaction management, and so on. If you need to develop these features from scratch every time you develop your application, the workload will be great and the reuse of your code will be poor. To address these issues, EJB provides a number of predefined services that integrate the services to be used in application development into the Java EE development environment. When these services need to be used, the program developer needs to declare or use a small amount of code to invoke these services and implement some complex control management mechanisms.

In application development, it is a mechanism that must be implemented in order to maintain the data consistency transaction management mechanism. If the transaction management mechanism is not implemented at the application level, it is easy to break the consistency of the data when the same business involves more than one record. And if you write the transaction mechanism code from scratch, the workload will be great. The solution of transaction management is provided in the container service of the EJB, and the program developer can easily create the transaction, process and control affairs and so on by virtue of this predefined solution.

Naming and registering in application development is also a cumbersome task. EJB also provides a container for naming and registering, and the EJB container and server provide the EJB with access to the naming service. Remote and local clients use these services to look for EJBS; The EJB component itself uses these services to query itself for the resources it needs. It is also true that program developers do not use code to implement naming and registration services in application development, and directly invoke naming and registration containers in EJB components. This container will automatically generate the relevant code to complete the required implementation of the function.

In addition, EJB components provide lifecycle management containers, security and access control containers, persistence containers, and so on, which allow program developers to write less code, not only to increase the efficiency of program development, but also to agree to these basic content solutions. This also helps later people to understand the source code, conducive to the subsequent upgrade of the application management software.

Third, the user interface and the underlying business work isolation.

In enterprise management, commonness and individuality coexist, which is also embodied in the enterprise management software. Like a business, if the manager's cultural background is different, or many of the same business has different management methods. This is in our program developer Professional terminology is the user interface is different. But the management model behind it is the same, meaning that its business functions are the same. such as an order management system developed in the Java language, the order Processing mechanism is the same, the relevant records are established in the database and the data validity is audited before the record is saved. However, different order types may be handled in a slightly different way. If for prepaid orders, must receive the customer's money to be able to place the order to the production department to arrange the production or the warehouse department to prepare the shipment, if for the warehouse order, then in the process processing does not need to go through the production the direct transfer to the warehouse shipment and so on. It is said that 10 different types of orders, its 80% function is the same, and 20% of the content because of management or other reasons for different. In this case, do you want to write 10 different code to achieve these 10 different requirements?

This is not so complicated in the EJB development model, because EJBS allow the development and deployment of business functions independent of the expression layer. As the above order management requirements, program developers can use the EJB model to achieve the underlying functions (80% of the common content), and then no need to redesign or development of the entire application or Sales order Management module, you can use different user interface to achieve the different needs of users. It's like the relationship between parents and their children. Now define the characteristics of the parents, and then depending on the needs of different children can (user interface). Because the children inherit all the characteristics of their parents. Then only need to implement some of the personality characteristics of the user can be grafted to the children. Therefore, the separation of business requirements from business functions and their independent characteristics are the biggest advantages of EJB development model. Application developers can use EJB to implement distributed applications, isolating user interfaces from underlying business functions.