What is SpringFramework and how did you use it?
The Spring Framework is an open source application framework that aims to make J2EE development easier. Unlike single-tier frameworks, such as Struts or Hibernate, Spring aims to help structure whole applications in a consistent, productive manner, pulling together best-of-breed single-tier frameworks to create a coherent architecture. Spring enables you to enjoy the key benefits of J2EE, while minimizing the complexity encountered by application code. The essence of Spring is in providing enterprise services to Plain Old Java Objects (POJOs). This is particularly valuable in a J2EE environment, but application code delivered as POJOs is naturally reusable in a variety of runtime environments.
J2EE applications tend to contain excessive amounts of "plumbing" code. Many code reviews repeatedly reveal a high proportion of code that doesn't do anything: JNDI lookup code, Transfer Objects, try/catch blocks to acquire and release JDBC resources. . . . Writing and maintaining such plumbing code proves a major drain on resources that should be focused on the application's business domain.
J2EE applications are hard to unit test without application server to have sufficiently high code coverage
Certain JEE technologies have been extremely complex to code -The EJB component model is unduly complex. Entity Beans, EJBs,
The technology that Spring is most identified with is Inversion of Control (or IoC), and specifically the Dependency Injection flavor of IoC. Spring is often thought of as an Inversion of Control container, although in reality it is much more.
Inversion of Control is best understood through the term the "Hollywood Principle," which basically means "Don't call me, I'll call you." Consider a traditional class library: Application code is responsible for the overall flow of control, calling out to the class library as necessary. With the Hollywood Principle, framework code invokes application code, coordinating overall workflow, rather than application code invoking framework code.
Dependency Injection is based on Java language constructs, rather than the use of framework-specific interfaces. Instead of application code using framework APIs to resolve dependencies such as configuration parameters and collaborating objects, application classes expose their dependencies through methods or constructors that the framework can call with the appropriate values at runtime, based on configuration.
Dependency Injection is a form of push configuration; the container "pushes" dependencies into application objects at runtime. This is the opposite of traditional pull configuration, in which the application object "pulls" dependencies from its environment. Thus, Dependency Injection objects never load custom properties or go to a database to load configuration — the framework is wholly responsible for actually reading configuration.
Bean factory
An application's beans are bootstrapped through an xml ApplicationContext file. Dependencies between beans in different layers are specified in this file.
Spring/Hibernate integration
Two options here:
1) Spring's JDBCTemplate can be used in DAO classes to do CRUD operations
2) Spring integrates Hibernate by simplifying data access objects, JPA.
DAO is interface
DAOImpl is a concrete class with @Transactional annotations
DAOImpl will be injected with an instance of SessionFactory in case of Hibernate, JdbcTemplate and Datasource if plain Spring without Hibernate
SessionFactory will be created by Spring using properties given for datasource in config file
The Transaction module supports programmatic and declarative transaction management for classes that implement special interfaces and for all your POJOs.
Spring catches any exception thrown in the underlying persistence technology and wraps it in a DataAccessException instance. The DataAccessException object is an unchecked exception, because it extends RuntimeException and you do not need to catch it if you do not want to.
Spring simplifies exposing POJOs as JMX beans.
Spring simplifies use of MBDs by using POJOs as message drivin POJOs.
Spring simplifies JNDI lookups
AOP
AOP enables you to capture the cross-cutting code in modules such as interceptors that can be applied declaratively wherever the concern they express applies — without imposing tradeoffs on the objects benefiting from the services.
There are several popular AOP technologies and a variety of approaches to implementing AOP. Spring includes a proxy-based AOP framework. This does not require any special manipulation of class loaders and is portable between environments, including any application server. It runs on J2SE 1.3 and above, using J2SE dynamic proxies (capable of proxying any number of interfaces) or CGLIB byte code generation (which allows proxying classes, as well as interfaces). Spring AOP proxies maintain a chain of advice applying to each method, making it easy to apply services such as transaction management to POJOs. The additional behavior is applied by a chain of advice (usually interceptors) maintained by an AOP proxy, which wraps the POJO target object.
Spring AOP allows the proxying of interfaces or classes. It provides an extensible pointcut model, enabling identification of which sets of method to advise. It also supports introduction: advice that makes a class implement additional interfaces. Introduction can be very useful in certain circumstances (especially infrastructural code within the framework itself).
Auditing: Applying a consistent auditing policy — for example, to updates on persistent objects.
Exception handling: Applying a consistent exception handling policy, such as emailing an administrator in the event of a particular set of exceptions being thrown by a business object.
Caching: An aspect can maintain a cache transparent to proxied objects and their callers, providing a simple means of optimization.
Retrying: Attempting transparent recovery: for example, in the event of a failed remote invocation.
The Spring Framework is an open source application framework that aims to make J2EE development easier. Unlike single-tier frameworks, such as Struts or Hibernate, Spring aims to help structure whole applications in a consistent, productive manner, pulling together best-of-breed single-tier frameworks to create a coherent architecture. Spring enables you to enjoy the key benefits of J2EE, while minimizing the complexity encountered by application code. The essence of Spring is in providing enterprise services to Plain Old Java Objects (POJOs). This is particularly valuable in a J2EE environment, but application code delivered as POJOs is naturally reusable in a variety of runtime environments.
J2EE applications tend to contain excessive amounts of "plumbing" code. Many code reviews repeatedly reveal a high proportion of code that doesn't do anything: JNDI lookup code, Transfer Objects, try/catch blocks to acquire and release JDBC resources. . . . Writing and maintaining such plumbing code proves a major drain on resources that should be focused on the application's business domain.
J2EE applications are hard to unit test without application server to have sufficiently high code coverage
Certain JEE technologies have been extremely complex to code -The EJB component model is unduly complex. Entity Beans, EJBs,
The technology that Spring is most identified with is Inversion of Control (or IoC), and specifically the Dependency Injection flavor of IoC. Spring is often thought of as an Inversion of Control container, although in reality it is much more.
Inversion of Control is best understood through the term the "Hollywood Principle," which basically means "Don't call me, I'll call you." Consider a traditional class library: Application code is responsible for the overall flow of control, calling out to the class library as necessary. With the Hollywood Principle, framework code invokes application code, coordinating overall workflow, rather than application code invoking framework code.
Dependency Injection is based on Java language constructs, rather than the use of framework-specific interfaces. Instead of application code using framework APIs to resolve dependencies such as configuration parameters and collaborating objects, application classes expose their dependencies through methods or constructors that the framework can call with the appropriate values at runtime, based on configuration.
Dependency Injection is a form of push configuration; the container "pushes" dependencies into application objects at runtime. This is the opposite of traditional pull configuration, in which the application object "pulls" dependencies from its environment. Thus, Dependency Injection objects never load custom properties or go to a database to load configuration — the framework is wholly responsible for actually reading configuration.
Bean factory
An application's beans are bootstrapped through an xml ApplicationContext file. Dependencies between beans in different layers are specified in this file.
Spring/Hibernate integration
Two options here:
1) Spring's JDBCTemplate can be used in DAO classes to do CRUD operations
2) Spring integrates Hibernate by simplifying data access objects, JPA.
DAO is interface
DAOImpl is a concrete class with @Transactional annotations
DAOImpl will be injected with an instance of SessionFactory in case of Hibernate, JdbcTemplate and Datasource if plain Spring without Hibernate
SessionFactory will be created by Spring using properties given for datasource in config file
The Transaction module supports programmatic and declarative transaction management for classes that implement special interfaces and for all your POJOs.
Spring catches any exception thrown in the underlying persistence technology and wraps it in a DataAccessException instance. The DataAccessException object is an unchecked exception, because it extends RuntimeException and you do not need to catch it if you do not want to.
Spring simplifies exposing POJOs as JMX beans.
Spring simplifies use of MBDs by using POJOs as message drivin POJOs.
Spring simplifies JNDI lookups
AOP
AOP enables you to capture the cross-cutting code in modules such as interceptors that can be applied declaratively wherever the concern they express applies — without imposing tradeoffs on the objects benefiting from the services.
There are several popular AOP technologies and a variety of approaches to implementing AOP. Spring includes a proxy-based AOP framework. This does not require any special manipulation of class loaders and is portable between environments, including any application server. It runs on J2SE 1.3 and above, using J2SE dynamic proxies (capable of proxying any number of interfaces) or CGLIB byte code generation (which allows proxying classes, as well as interfaces). Spring AOP proxies maintain a chain of advice applying to each method, making it easy to apply services such as transaction management to POJOs. The additional behavior is applied by a chain of advice (usually interceptors) maintained by an AOP proxy, which wraps the POJO target object.
Spring AOP allows the proxying of interfaces or classes. It provides an extensible pointcut model, enabling identification of which sets of method to advise. It also supports introduction: advice that makes a class implement additional interfaces. Introduction can be very useful in certain circumstances (especially infrastructural code within the framework itself).
Auditing: Applying a consistent auditing policy — for example, to updates on persistent objects.
Exception handling: Applying a consistent exception handling policy, such as emailing an administrator in the event of a particular set of exceptions being thrown by a business object.
Caching: An aspect can maintain a cache transparent to proxied objects and their callers, providing a simple means of optimization.
Retrying: Attempting transparent recovery: for example, in the event of a failed remote invocation.
No comments:
Post a Comment