Using spring framework to improve Java EE programming

Summary

Java EE programming is becoming more and more complex. Java EE has developed into a complex network of APIs, complicated programming and configuration. In response to this complexity, new frameworks and methodologies are emerging. These frameworks are highly dependent on a concept known as the IOC (inversion of control, reverse controls). This article explores some of the features and benefits of this approach, as it is related to Java-EE programming and makes it easier to program Java EE.

Brief introduction

Mark Twain's word is often quoted: "... The story about my death is an exaggeration. "There has been a lot of about. NET rumors, as well as the complexity of Java EE API can not be overcome and EJB as a component architecture is about to perish of the pop Geek (geek) culture. It's no big deal from an academic or just an imaginary standpoint, but the fact is that the J2EE/EJB API has undergone a Darwinian evolution. Readers with experience with DCOM or CORBA projects will understand what I mean. In the past, people were happy to hear about the good future of the EJB component model. The reality is that people are investing a lot in all aspects related to the Java EE. It may seem plausible to announce the abandonment of all previous work and to organize it, but it is not based on good business insights. EJB continues to evolve, and terminology, practices, and frameworks emerge (spring up), which make up for the inadequacy of the Java EE API. I'm not talking about spring appearing (UP), right?

I'm a consultant, and my job is to help build large, distributed applications, and usually Java EE applications. Therefore, I have the opportunity to experience the whole life cycle of many projects. In addition, I am able to take what I have just learned from a project that has just been completed and bring it directly into a new project. In a sense, my "natural selection" process has accelerated. I can say that the recent spring (more specifically IOC, or reverse control) has become more and more integrated into my project. In this article, I'll explore spring from the perspective of supporting or enhancing the Java EE project. More precisely, the spring framework can standardize many of the best practices of Java EE, as well as homogenize many ubiquitous Java EE patterns. Next, we'll look at a small part of spring's huge system, focusing on (in my humble opinion) the ability to help improve the functionality of the Java EE application.

Introduction to the IOC

In general, IOC is a technology that manages the association between classes. Yes, it's that simple! No one is isolated, as is the case for each object. Objects in the application are interdependent. It is often tedious and error-prone to express this dependency programmatically. The good IOC framework will be a declarative (through an XML configuration file) rather than programmatic (poor reliability in this way)-to concatenate interdependencies between applications.

The free use of interfaces is one of the main guidelines developed by the IOC. Interface programming greatly enhances the flexibility of the application, thus enhancing declarative association. Interface implementations are declared at runtime by the IOC configuration, which enables the "rebuild (rewire)" Association without affecting or impacting the actual application code. This is a recurring theme in the various IOC frameworks, and is generally a good practice to follow.

A small example

I like to understand concepts faster through examples. Here's a set of examples using the IOC; you'll see that the complexity of these examples is incremental. Most people use their dependency injection (inject dependency) function when they start using the IOC container-that is, declaratively associating an object. Using IOC helps create cleaner code, and it is generally more flexible and easier to rebuild an association between objects if necessary. The merit of the IOC is much more than dependency injection, and its extension is based on the dependency injection program.

We'll start with building simple dependency injection examples. The first example is used to illustrate two concepts already mentioned. The first concept is the ability of the IOC to build and correlate objects at runtime, and the second is the flexibility generated by the combination of interface coding. First, assume that the architect has submitted the UML shown in Figure 1.

Figure 1: Interface pluggable