Discuss the use of the Spring framework
Board bridge http://www.jdon.com 2004/08/25
Recently, Spring is very lively, because implementing IOC mode and AOP (see this stand-alumn), then set up a company, learn the lesson of JBoss, the document does not dare to charge, and the results ushered in a congratulations.
Spring The true essence is its IOC mode implemented BeanFactory and AOP, which extends on this basis. Some snakes are added.
In fact, it is said that everyone "surprised" is its IOC mode (which needs to know AOP using AOP. What is the IOC mode such as Spring? Is: When you write a program, just write the caller's interface code, the specific subclass instance can be implemented.
IOC mode does not know more, but when he knows that the object does not have to use New, as long as he configured in the configuration file, he feels fresh, in fact, this is the implementation of IOC mode, PicoContainer is another true light The amount of IOC mode is implemented, and the PicoContainer still takes a code to inject an object in a small container, and Spring takes the configuration file.
The configuration coding is actually advantageous, and the encoding can be checked by the development tool or the compiler, but when it is too dependent on the configuration, it will often appear because of a small error caused by care, if the debugger error is often written in the configuration file Capital Letters, I don't know how you are mood?
Spring recently published a book of Spring without Ejb. This is the truth, Spring and EJB are actually competitive, like black and white, if it is hard to use both, it is not coordinated, and some people so-called optimization EJB calls The rumor is the reason for the following analysis. Since Spring EJB has a defect, then use the Spring Hibernate architecture, but it brings new problems: uncharacted group distributed computing performance, can only run on one machine, specific analysis see: scalability and heavy / Light weight, who is the architecture of the practical system?
The uncoordinated Spring EJB is analyzed below, just as water and oil mix together. Currently, Spring EJB has two applications:
1. Spring does not introduce the EJB container, only the interface between the web and EJB, this location is more embarrassing, the web layer directly calls EJB method to relatively straightforward, why add a spring in the middle? Can I achieve web cache? Aop frame aspectWerkz with better performance; implement Web and EJB decoupling? Such tools, you can do a small frame implementation, you don't have to disturb Spring with the AOP and IOC dual burden.
2. Spring intervenes the EJB container, at this time, you need to configure the BeanFactoryPath value in your ejb-jar.xml to point to ApplicationContext.xml configured for EJB, then your EJB also needs to inherit Spring's SimpleFactoryBean.
Ok, now your SLSB (stateless session bean) is the following look:
Void updateuser () {MyService.UpdateUser (); // Enter a way to a pojo, real business logic package in this Pojo}
There are many "advantages", of course, the biggest "advantage" is:
Since the real business core is implemented in Pojo, as long as the ApplicationContext.xml configuration is changed, this, when debugging, the front desk can call Pojo directly, do not have to pass EJB, it is convenient to debug, this is a premise: they think debug EJB complex In fact, in JBuilder, combined with JUnit, test EJB is as convenient to test POJO, which is other branches, not discussed here. When deploying, change the ApplicationContext.xml configuration, guide the front desk to EJB.
It seems that it is very clever, there are two questions here, first, when is the change of EJB? Before continuous integration, there is a problem before it is there, and it does not carefully analyze.
The biggest advantage of this surface is: coarse granular transaction mechanism. The so-called coarse granular transaction mechanism, the earliest Web calls EJB Command mode in this post, there is discussion.
The following is description of what is a coarse granular transaction mechanism:
EJB method: public void updateuser () {service.Updateuser ();
Service is a pojo, the specific method may be updated two tables: public void updateuser () {updateTabel1 (); // update table1 updateTable2 (); // update Table2}
UpdateTable1 () is not rolled when UpdateTable2 () throws an exception. In this way, there is a false redundant record in Table1, and Table2 does not have this record.
So, how to make two table records, take a transaction mechanism, only the following writing can realize true transactions: Write two methods in the EJB method, because the EJB method is a transaction. Public void updateuser () {updateTabel1 (); // update table1 updateTable2 (); // update Table2}
Regarding the EJB automatic transaction mechanism, there is also a Taoist friend for testing, and the doubts of the transactions managed by JBoss containers.
If you are engaged in key transactions, it is a transaction with Money related operations. This coarse granular mechanism may harm you, then there seems to be a way to make up for affairs, do not use EJB container (CMT), using Spring in Service mechanism.
If you use the Spring transaction mechanism, the business core is implemented in Pojo, then I have a question: What do you want to put on EJB? At this point, you finally understand that Spring essence is competing with EJB. If the hard sleeve is used, it is just the lack of Spring is currently spent.
I am too amazing Spring, and he and the EJB relationship, just as the relationship between a shaped and people.
In order to avoid you think of sticky vias each time you use Spring, it is not as good as Spring without EJB, which is the original intention of Spring, and it is also a bestseller name.
