Archive

Posts Tagged ‘pojo’

Developing Spring Application in Eclipse IDE

November 25, 2009 3 comments

 

 

Spring Application Example:


Now that we have installed SpringIDE in Eclipse, let’s explore what we can do using Spring IDE and also create a Spring application. By integrating Spring IDE, we now have a Spring Project Wizard in the New Project option of Eclipse Workbench. We will start our Spring application with a demo project namely springide-demo. This is just to explore the SpringIDE features in Eclipse and not a tutorial on Spring application. This will help in getting started with our detailed tutorial ‘Exploring Spring Framework’ Series.

 

1. Creating a Spring Project:

  • Open the New project dialog box by choosing File Menu > New and Choose Spring Project below in the Wizard.

  • You will see the New Spring Project Dialog wizard. Here type the project name as “springide-demo” and keep all the options at their default values and click the Finish button.

  • This will create a new Spring Project. SpringIDE provides visual indicators in the Package Explorer view which will be shown in Java Perspective. Note the S symbol upon the project name. This is to indicate that this is a Spring project.

 

 

2. Create a working package and class in the project: Read more…

Spring Framework Terminologies

November 19, 2009 Leave a comment

 

Chapter 1: Terminologies

 

Design Patterns:

A design pattern is a conceptual general reusable solution to a commonly occurring problem in software design. A design pattern can’t be transformed directly into code. It is a template for how to solve a problem that can be used in many different situations. Design patterns such as Factory, Builder, Decorator, and Service Locator (to name a few) have widespread recognition and acceptance within the software industry. Design patterns are best practices given a name that describe what the pattern does, where the pattern is best applied and the problems that the pattern addresses etc.

 

Framework:

Framework is a step ahead of design patterns. It is basically a conceptually organized structure based on best practices and design patterns to address complex issues. A software framework is an abstraction in which generic functionality can be selectively overridden, specialized or extensible by user code. Frameworks are similar to software libraries in way that they are reusable code wrapped in a well-defined API. However unlike libraries, the overall program’s flow of control is not dictated by the caller, but by the framework. This inversion of control is the distinguishing feature of software frameworks.

 

Object-Oriented Frameworks:

An object-oriented framework is a semi-finished object-oriented application laid out on OOPS concepts such as Inheritance, Polymorphism, Abstraction and Encapsulation.   Object-oriented design patterns typically show relationships and interactions between classes or objects. It encapsulates common features that can be used across the same application or even different applications. Common examples of such frameworks include Apache Struts, JSF, and Spring etc. A framework-driven approach to application development usually involves integration of multiple object-oriented frameworks and creation of specific functionalities as extensions to these frameworks.

Every framework provides its own extension points called hotspots. Hotspots are specific to a framework, usually pertaining to integration (application programming/service provider interfaces) and configuration (external metadata). For example, the EJB 2.0 specifications define hotspots for Java bean objects to be deployed in an EJB container.

 

Inversion of Control:

Inversion of control is a generic principle and not a design pattern. Rather, it is a broad concept that is implemented by several design patterns.

Inversion of control is applied during communication between a framework and custom application logic. A common feature of frameworks is to maintain control of all communication activities within an application because of which the primary objective of an application module will only be to provide functionalities that can be invoked by the framework. Compare this to a scenario without frameworks, in which there is a significant effort on how the modules can invoke and manage each other.

 

Application modules won’t have to directly access each other’s capabilities when deployed on top of a framework. The same is also true for invocations from external entities. Instead, every request must be routed through the framework. The framework, in turn, can make multiple calls across more than one module in a controlled fashion before returning a result back to the caller.

In the light of what has been said so far, inversion of control can be summed up as:

“Don’t call us (framework); we’ll call you (application)”

 

Service Locator pattern: Read more…