Spring Core

1. what is Spring Framework?

 Spring is a light weight and open source framework created by Rod Johnson in 2003.

 Spring is a complete and a modular framework, meaning spring framework can be used for all
layer implementations for a an enterprise application or spring can be used for the
development of particular layer of a an enterprise application

For Example:

 struts: only for front end development

 Hibernate: only for database development, but with

 spring we can develop all layers

 Spring framework is said to be a simple and non-invasive means it doesn’t force a programmer
to extend or implement their class from any predefined class or interface given by Spring API,
but In case of web frameworks like struts framework, it will forces the programmer to extend
Action Class provided by struts API hence it is said to be invasive.

 Spring is light weight framework because of its POJO model.

 Spring Core

 Spring Framework made J2EE application development little easier, by introducing POJO model

POJO classes

 POJO stands for Plain Old Java Object. POJOs are used for increasing the readability and re-
usability of a program.

 POJOs have gained the most acceptance because they are easy to write and understand.

 The term POJO was introduced by Martin Fowler ( An American software developer) in 2000. it
is available in Java from the EJB 3.0 by sun microsystem

Properties of Pojo Class:

 The POJO class must be public.

 It must have a public default constructor.
 It may have the arguments constructor.
 All objects must have some public Getters and Setters to access the object values by other Java
Programs.
 The object in the POJO Class can have any access modifies such as private, public, protected.
But, all instance variables should be private for improved security of the project.

× A POJO class should not extend predefined classes.

× It should not implement pre-specified interfaces.
× It should not have any pre-specified annotation.

Example Of POJO:
 Spring Core

Java Bean

Java Bean class is also an object class that encapsulates several objects into a single file ( Bean Class
File). There are some differences between POJO and Bean.

Java Bean Properties:

 All Java Beans are POJOs but not all POJOs are Java Beans.
 Serializable i.e. they should implement Serializable interface.
 Fields should be private. This is to provide complete control on fields.
 Fields should have Getters or setters or both.
 A no-arg constructor should be there in a bean.
 Fields are accessed only by constructor or setter or getters.

POJO vs Java Bean

POJO Bean
It doesn’t have special restrictions other than It is a special POJO which have some restrictions
those forced by Java language.
It doesn’t provide much control on members. It provides complete control on members.
It cant implement Serializable interface. It should implement serializable interface.
Fields can be accessed by their names. Fields are accessed only by getters and setters.
Fields can have any visibility. Fields have only private visibility.
There may/may-not be a no-arg constructor. It must have a no-arg constructor.
 Spring Core

POJO classes and Beans both are used to define java objects to increase their readability and re
usability. POJOs don’t have other restrictions while beans are special POJOs with some restrictions.

Spring becomes popular because of the following reasons:

1. Simplicity
2. Testability
3. Loose Coupling

1. Simplicity

Spring framework is simple because as it is non-invasive, POJO and POJI model

2. Testability

 For executing the spring application, server is not mandatory, but for struts and EJB
applications we need a server for deploying the applications to execute them.
 If we want to test the application it may need lot of changes in the source and each time we
must restart the server to view the changes, which is little tedious and time taking but we can
over come this in Spring, for testing spring application server is not mandatory spring has it own
container to run the applications.
 Spring can be used to develop any kind of java application, means we can develop starting from
console application to enterprise level application

3. Loose Coupling

In spring objects are loosely coupled, this is the core concept of spring framework.

Tight Coupling Between Java Objects

In an object-oriented design, classes should be designed in a loosely coupled way. Loosely coupled
means changes in one class should not force other classes to change, so the whole application can
become maintainable and extensible.

Let's understand this by using typical n-tier architecture as depicted by the following figure:

 In the typical n-tier architecture, the User Interface (UI) uses Service layer to retrieve or save
data.
 The Service layer uses the BusinessLogic class to apply business rules on the data.
 Spring Core

 The BusinessLogic class depends on the DataAccess class which retrieves or saves the data to
the underlying database. This is simple n-tier architecture design.

The following is an example of Business Logic and DataAccess classes for a customer.

Step-1: Create class called DataAccess

Step-2: Create a class Called CustomerBusinessLogic as shown below

As We can see in the above example, the CustomerBusinessLogic class depends on the DataAccess
class. It creates an object of the DataAccess class to get the customer data.
 Spring Core

In the above example, CustomerBusinessLogic and DataAccess are tightly coupled classes because
the CustomerBusinessLogic class includes the reference of the concrete DataAccess class. It also
creates an object of DataAccess class and manages the lifetime of the object.

Problems in the above example classes:

1. CustomerBusinessLogic and DataAccess classes are tightly coupled classes. So, changes in
the DataAccess class will lead to changes in the CustomerBusinessLogic class. For example, if
we add, remove or rename any method in the DataAccess class then we need to change the
CustomerBusinessLogic class accordingly.

2. Suppose the customer data comes from different databases or web services and, in the
future, we may need to create different classes, so this will lead to changes in the
CustomerBusinessLogic class.

3. The CustomerBusinessLogic class creates an object of the DataAccess class using the new
keyword. There may be multiple classes which use the DataAccess class and create its
objects. So, if we change the name of the class, then we need to find all the places in our
source code where we created objects of DataAccess and make the changes throughout the
code. This is repetitive code for creating objects of the same class and maintaining their
dependencies.

4. Because the CustomerBusinessLogic class creates an object of the concrete DataAccess class,
it cannot be tested independently (TDD). The DataAccess class cannot be replaced with a
mock class.

To solve all of the above problems and get a loosely coupled design, we can use the Inversion Of
Controller (IoC) and Dependency Inversion Principle(DIP) together.

IoC is a principle, not a pattern. It just gives high-level design guidelines but does not give
implementation details. We are free to implement the IoC principle the way we want.

Inversion Of Controll(IOC) is a software Design Principle, independent of language which doesn’t

actually creates the objects but describes the way in which object is being created.

The following pattern (but not limited) implements the IoC principle.
 Spring Core

Let's use the Factory pattern to implement IoC in the above example, as the first step towards
attaining loosely coupled classes.

Step-1: create a simple Factory class which returns an object of the DataAccess class as shown
below.

Step-2: Now, use this DataAccessFactory class in the CustomerBusinessLogic class to get an object of
DataAccess class.

As we can see, the CustomerBusinessLogic class uses the

DataAccessFactory.GetCustomerDataAccessObj() method to get an object of the DataAccess class
instead of creating it using the new keyword.
 Spring Core

Thus, we have inverted the control of creating an object of a dependent class from the
CustomerBusinessLogic class to the DataAccessFactory class.

This is a simple implementation of IoC and the first step towards achieving fully loose coupled
design.

we will not achieve complete loosely coupled classes by only using IoC. Along with IoC, we also need
to use DIP, Strategy pattern, and DI (Dependency Injection).

Dependency Inversion Principle (DIP)

DIP is one of the SOLID object-oriented principle invented by Robert Martin (a.k.a. Uncle Bob)

DIP Definition

1. High-level modules should not depend on low-level modules. Both should depend on the
abstraction.
2. Abstractions should not depend on details. Details should depend on abstractions.

 So far we implemented the factory pattern to achieve IoC. But, the CustomerBusinessLogic
class uses the concrete DataAccess class. Therefore, it is still tightly coupled, even though we
have inverted the dependent object creation to the factory class.

 Let's use DIP on the CustomerBusinessLogic and DataAccess classes and make them more
loosely coupled.
 Spring Core

 As per the DIP definition, a high-level module should not depend on low-level modules. Both
should depend on abstraction.
 So, first, decide which is the high-level module (class) and the low-level module. A high-level
module is a module which depends on other modules.
 In our example, CustomerBusinessLogic depends on the DataAccess class, so
CustomerBusinessLogic is a high-level module and DataAccess is a low-level module.
 So, as per the first rule of DIP, CustomerBusinessLogic should not depend on the concrete
DataAccess class, instead both classes should depend on abstraction.

The second rule in DIP is "Abstractions should not depend on details. Details should depend on
abstractions".

What is an Abstraction?

 Abstraction and encapsulation are important principles of object-oriented programming. In

English, abstraction means something which is non-concrete.
 In programming terms, the above CustomerBusinessLogic and DataAccess are concrete classes,
meaning we can create objects of them.
 So, abstraction in programming means to create an interface or an abstract class which is non-
concrete. This means we cannot create an object of an interface or an abstract class.
 As per DIP, CustomerBusinessLogic (high-level module) should not depend on the concrete
DataAccess class (low-level module). Both classes should depend on abstractions, meaning both
classes should depend on an interface or an abstract class.
 Now, what should be in the interface (or in the abstract class)? As we can see,
CustomerBusinessLogic uses the GetCustomerName() method of the DataAccess class (in real
life, there will be many customer-related methods in the DataAccess class). So, let's declare the
GetCustomerName(int id) method in the interface, as shown below.

 Now, implement ICustomerDataAccess in the CustomerDataAccess class, as shown below (so,

instead of the DataAccess class, let's define the new CustomerDataAccess class).

 Now, we need to change our factory class which returns ICustomerDataAccess instead of the
concrete DataAccess class, as shown below
 Spring Core

 Now, change the CustomerBusinessLogic class which uses ICustomerDataAccess instead of the
concrete DataAccess, class as shown below.

 Thus, we have implemented DIP in our example where a high-level module

(CustomerBusinessLogic) and low-level module (CustomerDataAccess) are dependent on an
abstraction (ICustomerDataAccess). Also, the abstraction (ICustomerDataAccess) does not
depend on details (CustomerDataAccess), but the details depend on the abstraction.

Advantages of DIP

 The advantages of implementing DIP in the above example is that the CustomerBusinessLogic
and CustomerDataAccess classes are loosely coupled classes because CustomerBusinessLogic
 Spring Core

does not depend on the concrete DataAccess class, instead it includes a reference of the
ICustomerDataAccess interface.

So now, we can easily use another class which implements ICustomerDataAccess with a different
implementation.

Still, we have not achieved fully loosely coupled classes because the CustomerBusinessLogic class
includes a factory class to get the reference of ICustomerDataAccess. This is where the Dependency
Injection pattern helps us.

Types Of IOC

 Inversion of Controll means the separating the implementation of an object from how the
object is being created.
 In case of Spring framework, the framework will take care of the dependency object creation
and injecting the created dependency object to the dependent object. Being a programmer we
just need to focus on business logic implementation rather how the object has been created
and injected.
 There are two type of implementations of IOC Principle.

1. Dependency Lookup
2. Dependency Injection

Dependency Injection

 The process of pulling the dependency objects from the container/entity where the objects are
being created is called as DI.
 We use the DI along with Strategy pattern together to move the object creation logic
completely from the dependent object to an external container/entity called as IOC Container.
 DI is a design pattern used to implement IOC(Design Principle).
 In this type of IOC, when one object is collaborating with another object lets say when Customer
Business Logic Object is collaborating with the Data access object, then a third party
 Spring Core

entity/container will creates the Data Access object (dependency) frist and then make it
available to the dependent object I.e. customer business logic.
 Now the customer business logic object need to go to that external/third party entity and pull
the required dependency from the container/entity to the customer business logic class called
as dependent class.

The following dependency injections are supported by the spring framework:

1. Setter Injection
2. Constructor Injection
3. Interface Injection

 Dependency Injection (DI) is a design pattern used to implement IoC. It allows the creation of
dependency objects outside of a dependent class and provides those objects to a class through
the above described 3 ways.
 Using Dependency Injection (DI), we move the creation and binding of the dependency objects
outside of the dependent class.
 The Dependency Injection pattern involves 3 types of classes.

1. Client Class: The client class (dependent class) is a class which depends on the service class
2. Service Class: The service class (dependency) is a class that provides service to the client class.
3. Injector Class: The injector class injects the service class object into the client class.

The following figure illustrates the relationship between these classes:

As we can see, the injector class creates an object of the service class, and injects that object to a
client object. In this way, the DI pattern separates the responsibility of creating an object of the
service class out of the client class.

Example:

Step-1:

public interface ICustomerDataAccess

{
string GetCustomerName(int id);
}
 Spring Core

Step-2:

public class CustomerDataAccess implements ICustomerDataAccess

{
public CustomerDataAccess() {
}

public string GetCustomerName(int id) {

return "Dummy Customer Name";
}
}

Step-3:

public class DataAccessFactory

{
public static ICustomerDataAccess GetCustomerDataAccessObj()
{
return new CustomerDataAccess();
}
}

Step-4:

public class CustomerBusinessLogic

{
ICustomerDataAccess _custDataAccess;

public CustomerBusinessLogic()
{
_custDataAccess = DataAccessFactory.GetCustomerDataAccessObj();
}

public string GetCustomerName(int id)

{
return _custDataAccess.GetCustomerName(id);
}
}

 The problem with the above example is that we used DataAccessFactory inside the
CustomerBusinessLogic class.
 So, suppose there is another implementation of ICustomerDataAccess and we want to use that
new class inside CustomerBusinessLogic, Then, we need to change the source code of the
DataAccessFactory class as well.
 The Dependency injection pattern solves this problem by injecting dependency objects via a
constructor, a setter, or an interface.
 Spring Core

As we see, the CustomerService class becomes the injector class, which sets an object of the service
class (CustomerDataAccess) to the client class (CustomerBusinessLogic) either through a constructor,
a setter, or an interface to achieve loose coupling.

Constructor Injection

When we provide the dependency through the constructor then we call it as constructor injection.

Example:
 Spring Core

 In the above example, CustomerBusinessLogic includes the constructor with one parameter of
type ICustomerDataAccess. Now, the calling class must inject an object of
ICustomerDataAccess.

 As we can see in the above example, the CustomerService class creates and injects the
CustomerDataAccess object into the CustomerBusinessLogic class.
 Thus, the CustomerBusinessLogic class doesn't need to create an object of CustomerDataAccess
using the new keyword or using factory class.
 The calling class (CustomerService) creates and sets the appropriate DataAccess class to the
CustomerBusinessLogic class. In this way, the CustomerBusinessLogic and CustomerDataAccess
classes become "more" loosely coupled classes.

IoC Container

IoC Container (a.k.a. DI Container) is a framework for implementing automatic dependency injection.
It manages object creation and it's life-time, and also injects dependencies to the class.

The IoC container creates an object of the specified class and also injects all the dependency objects
through a constructor, a setter or an interface at run time. This is done so that we don't have to
create and manage objects manually.
 Spring Core

The IOC Container is responsible for

 Instantiate the application class

 Configure the object

 Assembles the dependencies between the objects

In Spring there are two types of IOC Containers. They are:

 org.springframework.beans.factory.BeanFactory

 Org.springframework.context.ApplicationContext

The spring core container uses the dependency injection(DI) to manage the components/objects
that make up an application.

In this IOC, consider when our class object need to get any primitive values or it need to access any
other class objects or it may need any collection type to access then, some external person will
provide the required things (primitive values or objects or collections) to our class object.

In IOC, our class is not responsible to get all these collaborating (required things like primitive values,
Objects and collections) values explicitly.

In Spring framework, here one external person who will provide [Injects] all the required things to
our spring bean class is the spring ioc container.

Types of dependency injections

For injecting the required things to the current spring class (spring bean) , spring ioc container will do
this in different ways:

 Setter injection
 Construction injection
 Spring Core

 Interface injection

But in spring we have only setter, constructor injections but not interface injection, In spring 2.x we
have interface injection