Explore the use of the Spring framework (from JD.com)

Exploring the use of spring frameworks

Banqiao Renren http://www.jdon.com

Recently, spring was very popular because of the implementation of the IOC model and AOP (see the column on this site), and then set up a company to learn the lessons learned from the previous JBoss. The document did not charge fees, and a congratulation came to the fore.

The essence of spring is beanfactory and AOP implemented in its IOC mode. Its own extended functions are quite superfluous.

To put it bluntly, what everyone is surprised about is its IOC mode (it is difficult to understand AOP when using the AOP function). So what is the IOC mode like spring? That is, when compiling a program, you only need to write the interface code of the caller. The specific subclass instance can be implemented through configuration.

There are not many people who know the IOC mode. However, when he knows that the generated object does not need to use new, he just needs to configure it in the configuration file, in fact, this is the implementation of the IOC mode. picocontainer is another truly lightweight IOC mode implementation. picocontainer still uses code to inject objects into a small container, while spring uses the configuration file.

Configuration-based encoding actually has advantages and disadvantages. encoding can be checked by development tools or compiler errors. However, when you rely too much on configuration, small errors may often occur due to carelessness, if debugging program errors are often caused by uppercase or lowercase letters in the configuration file, how do you feel?

Spring has recently published a book about spring without EJB. To tell the truth, spring and EJB are actually competing, just like black and white. If they are used together, they seem uncoordinated, it is not a rumor that some people call to optimize EJB calls. The reasons will be analyzed below. Since spring + EJB is defective, we can directly use the spring + hibernate architecture, but it brings about a new problem: No cluster distributed computing performance, and we can only run it on one machine, for detailed analysis, see: scalability and heavy/lightweight. Who is the primary choice for the architecture of a practical system?

Next we will analyze the inconsistency between spring and EJB, just as water and oil are stirred together for use.
Currently, spring + EJB has two application methods:

1. Spring does not intervene in the EJB container and only serves as the interface between the web and EJB. This location is awkward. The web layer directly calls the EJB method directly and quickly. Why should we add spring in the middle? Can Web Cache be implemented? Use the better performance AOP framework aspectwerkz to implement web and EJB decoupling? With more such tools, you can build a small framework for implementation, so you don't have to bother with spring with the double burden of AOP and IOC.

2. Spring is involved in the EJB container. In this case, you need to configure the beanfactorypath value in your ejb-jar.xml to point to the applicationcontext. xml you configured for EJB, then your EJB also needs to inherit spring's simpleremotestatelesssessionproxyfactorybean.

Now, your slsb (stateless session bean) is like this:

Void updateuser (){
　　　　
Myservice. updateuser (); // delegate to a pojo method. The real business logic is encapsulated in this pojo.

}

This operation has many "advantages", of course, the biggest "advantages" are:

Because the real business core is implemented in pojo, you only need to change applicationcontext. xml configuration. In this way, the front-end can directly call pojo during debugging without using ejbs. This is a prerequisite: they think that the debugging of ejbs is complicated, in JBuilder, combined with JUnit, testing EJB is as convenient as testing pojo. This is another branch and is not discussed here. When deployed and used, modify the applicationcontext. xml configuration to instruct the front-end to call EJB.

It seems very clever. There are two questions here. First, when should we guide the EJB change? There are problems before or after continuous integration. I will not analyze them carefully here.

　　This superficial clever advantage brings about the biggest problem: coarse-grained transaction mechanism. The so-called coarse-grained transaction mechanism was first seen in the webcall EJB command mode of PetStore, which was discussed in this post.

The following code describes what is a coarse-grained transaction mechanism:

EJB method:
Public void updateuser (){
Service. updateuser ();
}

Service is a pojo. The specific method may be to update two tables:
Public void updateuser (){
Updatetabel1 (); // update Table1
Updatetable2 (); // update Table2
}

When updatetable2 () throws an exception, updatetable1 () does not roll back. In this way, Table1 has an invalid redundant record, while Table2 does not.

Then, how can we make the two tables record consistent and adopt the transaction mechanism, only the following writing can realize the real transaction:
Write two methods in the EJB method, because the EJB method body is a transaction by default.
Public void updateuser (){
Updatetabel1 (); // update Table1
Updatetable2 (); // update Table2
}

About the automatic transaction mechanism of EJB, a Taoist recently tested the transaction mechanism, and wondered about the container-managed transactions in JBoss.

If you are engaged in a key transaction, it is a transaction with money-related operations, and this coarse-grained mechanism may hurt you, there seems to be a way to make up for the transaction, without using the EJB container transaction (CMT ), use Spring transaction mechanism in service.

If Spring transaction mechanism is used and the Business Core is implemented in pojo, I have a question: What should I do with EJB? At this point, you finally understand that spring is essentially competing with EJB. If you use EJB hard, you only need to use its cluster distributed function, which is exactly what spring currently lacks.

I'm amazed at Spring's delicate and strange nature. He has a relationship with EJB, just like the relationship between profile and person.

In order to prevent you from thinking of a vague shape every time you use spring, it is better to use spring without EJB, which is also the original intention of spring and a best-selling name.

To make it easier for beginners to master spring, a new article "Spring Quick Start" is added in the teaching area of this site, which is easy to understand and specifically targeted at VIP members.