Understanding Spring Framework

About Spring Framework, you may have heard a lot of discussions this summer. In this article, I will try to explain what Spring can do, and how can I think it can help you develop J2EE applications. Another Framework? You may be thinking "it is another Framework". When there are already many open source (and proprietary) J2EE Framework, why should you read this article or download Spring framework? I believe that Spring is unique, because of several reasons:. It is located in the field of many other popular frameworks. Spring Focus provides a way to manage your business objects. Spring is comprehensive and modular. Spring has a hierarchical architecture, which means that you can choose any part of it isolated, and its architecture is still inherently stable. So from your study, you can get the biggest value. For example, you may choose to use Spring to simplify the use of JDBC, or to manage all business objects. Its design helps you write easy-to-test code from the bottom. Spring is an ideal Framework for testing driven projects. Spring For your project, it doesn't need more than one Framework. Spring is a potential one-stop solution, which is positioned in most infrastructure associated with typical applications. It also involves content that other frameworks have not considered. Although it is just an open source project starting from February 2003, Spring has a longer historical roots. This open source project is the foundation code in the "Expert One-ONE J2EE Design and Development" book published in 2002. This book shows the infrastructure behind Spring. However, this infrastructure concept is dating back to 2000, and reflects my experience in which I have successful business engineering development infrastructure. From January 2003, Spring has settled on SourceForge. There are now 10 developers, of which 6 are highly investive active molecules. Spring's architectural benefits Before we entered the details, let's take a look at some benefits to a project:. Spring can effectively organize your intermediate object, whether you choose to use EJB. If you only use Struts or other Framework that contains J2EE unique APIs, you will find Spring to pay attention to the problem left. Spring can eliminate excessive use of Singleton in many projects. According to my experience, this is a major problem that reduces the testability and object-oriented characteristics of the system. . Spring can eliminate the need for custom files using a variety of formats, throughout the application and engineering, can be configured by a consistent way. I have confused, a particular class to find a psychedelic attribute keyword or system attribute, do you have to read Javadoc or even source coding? With Spring, you can see the JavaBean property of the class very simply. Invert control (discussed below) Help Complete this simplification. . Spring can promote good program habits through the interface instead of classes, and reduce programming costs to almost zero. Spring is designed to let the apps that use it as little depends on his APIs. Most business objects in Spring applications do not depend on Spring. Applications built using Spring are easy to test. Spring enables the use of EJBs into an implementation choice instead of the application architecture. You can choose to use Pojos or Local EJBS to implement the business interface, but it will not affect the call code. . Spring helps you solve many problems without using EJB. Spring provides an EJB replacement that is suitable for many web applications. For example, Spring can use AOP to provide declarative transactions without using an EJB container, if you just need to deal with a single database, no JTA implementation is required. . Spring provides a consistent framework for data access, whether using JDBC or O / R mapping products (such as hibernate).

Spring really allows you to solve your problem through the easiest enough solution. These features are very valuable. What can SPRING do? Spring provides a number of features, here I will quickly display all major aspects in turn. Mission Description: First, let us clarify the Spring range. Although Spring covers many aspects, we already have a clear concept, what should be involved and what should not be involved. The main purpose of Spring is to make J2EE easy to use and promote good programming habits. Spring does not revisit existing things. Therefore, in Spring you will find the package without a log record, no connection pool, no distributed transaction scheduling. These have open source projects (such as Commons Logging, or Commons DBCP is used as a data connection pool), or by your application server. Because of the same reason, we did not provide O / R mapping layers, which have good solutions such as Hibernate and JDO. Spring's goal is to make the existing technology more easily. For example, although we don't have underlying transaction coordination, we provide an abstract layer to cover JTA or any other transaction strategy. Spring does not compete with other open source projects unless we feel that we can provide new things. For example, like many developers, we have never been happy for Struts, and feel in the MVC Web Framework. In certain areas, such as lightweight IOC containers and AOP frames, Spring has direct competition, but there is no more popular solutions in these areas. (Spring is a pioneer in these areas.) Spring also benefits from intrinsic consistency. All developers are singing the same praise songs, the base idea is still those designed and developed by Expert One-ON-One J2EE. And we have been able to use some main concepts, such as invert control, to handle multiple fields. Spring is portable between the application server. Of course, the portability is always challenged, but we avoid any specific platform or non-standardization and support users on WebLogic, Tomcat, Resin, JBoss, WebSphere, and other application servers. The design of the inverted control container Spring is the org.springframework.beans package, designed to work with JavaBeans. This package is generally not directly used by the user, but as a foundation for more other functional services. The next higher level is "bean factory". Spring Bean Factory is a normal factory that enables objects to get in name, and can manage the relationship between objects. Bean factory supports two object modes: Singleton: In this mode, there is a shared object instance with a specific name, which is obtained when looking up. This is the default, and it is most often used. It is an ideal pattern for stateless objects. .Prototype: In this mode, a separate object will be created each time you get. For example, this can be used to allow users to have their own objects. Because org.springframwork.beans.Factory.BeanFactory is a simple interface, it can be implemented for the underlying storage method. You can easily implement your own BeanFactory, although few users need. The most common definition is: .xmlbeanfactory: An XML structure that can be parsed simple and intuitive definition classes and named object properties. We provide a DTD to make the writing easier. .ListableBeanFactoryImpl: Provides a bean definition stored in the properties file, and can create BeanFactories by programming.

Each bean definition may be a pojo (definition by class name and JavaBean initial attribute) or a FactoryBean. A indirect layer has been added to the FactoryBean interface. Typically, this is used to use AOP or other methods to create a proxy object: for example, adding a proxy for declarative transaction management. (This is similar to the EJB listening, but it is easier in practice.) BeanFactories can selectively participate in a hierarchy, definition based on inheritance from the ancestors. This makes sharing of public configuration across applications possible, although individual resources, such as Controller Servlets, also have their own independent objects. This motivation using JavaBeans is described in the fourth chapter of , with free PDF on the THESERVERSIDE website (http://www.theserverside.com/resources/article .jsp? l = rodjohnsoninterview). With the BeanFactory concept, Spring becomes an inverted container. (I don't like the terminology of Container because it makes people think of the weight-level container, such as the EJB container. Spring BeanFactory is a container created by a line of code and does not require a special deployment step.) Behind the inverted control The concept is in the HollyWood principles, often expressed: "Don't call me, i'll call you." IOC moves control responsibilities into the framework and detaches the application code. Where the configuration is involved, it means that in the traditional container architecture, such as EJB, one component can call the container and ask "Where do I need it to do the object X?"; Use IOC container only need to point out Components require X objects, which will be provided to it at runtime. The container makes this description based on the method name or may be as XML according to the configuration data. Several important benefits of invert control. Such as: Components do not need to find collaborators at runtime, so they can write and maintain more simple. In Spring's Ioc versions, components express their dependence on other components that expose JavaBean's Setter method. This is equivalent to finding the EJB to find through JNDI, and EJB looks out that the developer needs to write code. The same reason, the application code is easier to test. The Javabean property is simple, Java core, and easy test: only written a JUnit test method that contains its own use to create objects and setting related properties. A good IOC implementation hides strong types. If you use an ordinary factory to find a partner, you must convert the return result into the desired type by type conversion. This is not a major problem, but it is not anger. With IOC, you express strong type dependencies in your code, the framework will be responsible for type conversion. This means that the type mismatch will result in an error when the framework configuration is applied; in your code, you don't have to worry about the type conversion exception. Most business objects do not depend on the IOC container API. This makes it easy to use legacy code, and it is easy to use objects or in the container or not in the container. For example, Spring users often configure the Jakarta Commons DBCP data source as a Spring Bean: No need to do any custom code to do this. We say that an IOC container is not invasive: use it does not make your code depend on its APIS. Any Javabena can become a component in Spring Bean Factory. Finally, it should be emphasized that IOC is different from the architecture of the traditional container (eg, EJB), and the application code is minimized by the container.

This means that your business object can potentially run on a different IOC frame - or in any framework - no code change. With my experience and as a Spring user, it is not easy to over-emphasize the benefits of IOC to the application code. IOC is not a new concept, but it has just arrived at the J2EE group. There are some optional IOC containers: NOTABLY, APACHE AVALON, PicoContainer and HiveMind. Avalon will not be particularly popular, although it is very powerful and has a long history. Avalon is quite heavyweight and complex, and it looks more invasive than the new IOC solution. PicoContainer is a lightweight and emphasizes the expression dependence of constructors rather than JavaBeaN properties. Unlike Spring, its design allows each type of object definition (possibly limitable result from its rejection of metadata outside the Java code). As a comparison with Spring and Picocontainer And Other IoC Frameworks, see article http://www.springframework.org/docs/lightweight_container.html. This industry contains a PicoContainer site link. Spring beanfactories is very lightweight. Users have successfully applied them in Applets and separate SWING applications. (They also work well in the EJB container.) There is no special deployment step and the perceived startup time. This capability indicates that a container can play a very value at any level of the application. The Spring BeanFactory concept applies to Spring overall, and is a key reason for Spring so inherent. In the IOC container, Spring is also unique, which uses IOC as the foundation concept throughout the frame. For use developers, most importantly, one or more beanfactory provide a defined business object layer. This is similar, but it is easier than the Local Session Bean layer. Unlike EJBs, objects in this layer may be related, and their relationship is managed by their own Factory. There is a great definition of a clear business object layer to a successful architecture. Spring ApplicationContext is the sub-interface of BeanFactory, which supports the following: message is looking for, international support. Event mechanism, allow application objects to publish and register as event monitors. Portable files and resource access XMLBeanFactory example Spring users are usually in XML "bean Define the application in the file. Spring's XML bean defines the root of the document is a element. This element contains one or more definitions. We generally specify a bean defined class and attribute. We must also specify the ID as an identifier, we will use this flag in the code. Let's look at a simple example, often see the three application objects in J2EE applications:. J2EE Datasource. Use DAO's DAO. Use DAO's business objects in the process in the following example, we use one BasicDataSource from the Jakarta Commons DBCP project. This Class (like other existing Class) can be simply applied in the Spring Bean Factory because it provides a configuration in JavaBean format. The CLOSE method that needs to be called when Shutdown can be registered with Spring's "Destroy-Method" attribute to avoid BasicDataSource needs to implement any spring interface.

Code: com.mysql.jdbc. Driver jdbc: mysql: // localhost: 3306 / mydb ROOT All the properties of the BasicDataSource we are interested in String type, so we use the element to specify their value. If necessary, Spring converts String using a standard Javabea property editor mechanism to represent other types. Now we define DAO, it has a bean reference to DataSource. The relationship between the bean is specified by the element:

Code:

Business object has a DAO reference and an INT type property (ExampleParam):

Code: 10

The relationship between objects is generally set in configuration, just like this example. We think this is a good thing. In any case, Spring also provides our support for "AutoWire", a la PicoContainer, where it can point out the dependencies between Beans. The limitations of doing this - if you use PicoContainer- if there is a special type of multiple beans, it will be impossible to make a type of judgment to be related to which instance. Ok, after Factory initialized, unsatisfactory reliance may be captured. (Spring also provides an optional dependency check for a clear configuration, which can accomplish this) If we don't want to write their relationship, in the above example, we can use the AutoWire feature as follows: 10 use with this usage, Spring will identify the exampleBusinessObject The DataSource property should be set to the DataSource implementation found in the current BeanFactory. In the current BeanFactory, an error will occur if the Bean of the required type does not exist or more than one. We still have to set an ExampleParam property because it is not a reference. AutoWire support and dependencies have just been added to Spring 1.0 M2 (to 10/20, 2003). All other features discussed herein are included in the current 1.0 m1 version. External relationships from Java code have great benefits than hard coding, because changed XML files without changing a line Java code. For example, we can simply changing the bean definition of MyDataSource to provide different bean class to use an optional connection pool, or a test data source. In a separately optional XML fragment, we can get a data source from Application Server with Spring JNDI Location FactoryBean. Let us now look at the Java code in the example in the business object. Note that there is no dependence on Spring in the code listed below. Unlike EJB containers, Spring BeanFactory is not intrusive: you usually don't need to encode them in the application object. Code: public class ExampleBusinessObject implements MyBusinessObject {private ExampleDataAccessObject dao; private int exampleParam; public void setDataAccessObject (ExampleDataAccessObject dao) {this.dao = dao;} public void setExampleParam (int exampleParam) {this.exampleParam = exampleParam;} public void myBusinessMethod ( ) {// do stuff using dau}}