• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Scott Selikoff
  • salvin francis
  • Piet Souris

What are the advantages of Spring Framework? why it is needed ?

Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I started reading & programming small web applications in Spring.But I am not getting the exact need of Spring framework.?
Why it is needed?what are the advantages of Spring Framework ?Please help me to understand.
Thank you.
Ranch Hand
Posts: 236
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Spring is a light-weight framework that works based on a pattern called Inversion of Control or Dependency Injection.
Here, instead of you creating dependencies between different objects, Spring does it for you.

So you define different beans/objects in an xml file, and Spring reads this file and creates objects and sets dependencies.
It just makes your code more readable. Also faster development time.
Spring also helps testing of your code easier.
Posts: 4705
IntelliJ IDE Python Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Surendra Kumar wrote:Spring is a light-weight framework that works based on a pattern called Inversion of Control or Dependency Injection


Surendra Kumar wrote:Here, instead of you creating dependencies between different objects, Spring does it for you.

True. Among other things, but this is it's primary function

Surendra Kumar wrote:So you define different beans/objects in an xml file, and Spring reads this file and creates objects and sets dependencies.

True. Also Spring 2.5+ allows you to use annotations instead of xml.

Surendra Kumar wrote:It just makes your code more readable.

Not necessarily true. The indirection created by managing your dependencies with Spring can be quite difficult to follow unless you have a good IDE with very good Spring integration. Sometimes just using Java is all you would want or even need.

Surendra Kumar wrote:Also faster development time.

Not unless you're well versed in Spring, and even then I'd say it's not always quicker.

Surendra Kumar wrote:Spring also helps testing of your code easier.

Following the Dependency Injection pattern, however you do it, most certainly does make testing easier. I don't think Spring itself makes testing easier. In fact in my experience it often makes it harder, and slower.
Posts: 43011
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Like any framework it is not needed at all. It makes certain tasks easier, which may or may not help with any particular project. At this point Spring is huge - lots and lots of disparate functionalities come together underneath its umbrella, any particular one of which may or may not be applicable to the tasks at your hand. So be aware that learning "Spring" could be something that takes years to master... or mere days, if you restrict yourself to small aspects of it. Or you may find that other frameworks do a better job at solving the particular problems that you need to solve.
Posts: 2759
Eclipse IDE Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The biggest advantages are dependency injection and aspect oriented programming. I won't go into AOP here because the wonders of DI make his post very long

To understand why dependency injection is useful, you need to first understand the "pain" when you don't have dependency injection. For those of us who have gone through the pain, DI is like a relief. You really need to understand the whole sordid tale of Factory patterns before you understand why DI is like the holy grail of factory patterns

Let's say you have 2 classes, a service class that contains business logic, another which contains the data access. Both these classes are connect through an interface. The data access class implements a data access interface, and service class calls the data access through the interface. Fine! This is a good way of designing your code because you have hidden the implementation details of how data is stored inside your data access class. Any time you want to change how your data is stored, you simply change the implementation of data access class. Super!

But wait a minute. How does the service class get an object of the data access class. Simplest thing to do is instantiates the data access class , right? Yes. But there are problems here. You started of building your service class independent of the implementation of the data class, and in 95 % of your code it is independent! except that during initialization it know the data access class. Also. If the data access class needs some initialization and cleanup, you have to put that code into your service class. Not good. You made the service class independent, but you didn't get all the way there. Besides this, an average application has many service classes and several data access classes. One data access class might be used in many service classes. And changing the data access class will cause you to change the code in multiple service classes. Not good at all

So what you need to do is centralize the creation, initialization and cleanup code for data access classes. Enter the Factory pattern. Here the factory class will be responsible for creating an instance of the data access class, and the service classes will get the instance from the factory. This solves the problem but not entirely. Your service classes are still dependent on the factory. Also, if your initialization logic needs parameters ( like db urls, etc) the service classes will need to pass it to the factory, which means the service class needs to have some info about the data access class

Of course you can have the factory classes read the Init params from a property file. This is great in making the service class independent of the data access. However, now you have all this code that reads Init parameters spread out among factory classes

So, why not have just one factory class responsible for creating all objects in the application. There is a property file that contains the initialization parameter for each object to be created. The factory class creates all the objects, inits them and stores references to them. Whenever an object needs a reference to another object, it asks the factory for the reference. This is essentially the Service Locator pattern. You solve a lot of big problems with Service Locator, but you create another big one : everyone is dependent on the service locator. One day you need to reuse your class somewhere else, but if you take his class you need to take service locator too, and if you take service locator, you need to take every other class that the service locator inits. Bugger. You made a nice reusable class, but you can't use it because it is connected to this whole mess.

This is where DI comes in, but before we get there, let's talk about how Inversion Of Control (IoC) is useful. So, in the above Service Locator pattern , the properties file contains parameters that describe how to init the objects of each class. However, the class to be created is hard coded in the service locator. Someone came up with a great idea of having a reusable Service Locator. Put the name of the class itself in the property file, and the service locator can instantiates the class using reflection. The property file can contain enough information that tells the Service Locator how to create and init the class. This is IOC. The object being created is determined at runtime not compile time. The advantage here is you don't need to make a code change in the service locator when your classes change

So, now going back to the problem of everything being dependent on Service Locator. Some smart guy/gal looked at Service Locator and says "why can't the service locator know which objects are dependent n which object? That way everyone wouldn't have to call the service locator, right? The locator can just give it to them" so for example, if the service locator can create the objects of service classes and objects of data access classes, and give references of the data access classes to the service classes. So now the service classes are dependent only on the interface of data acces classes. The service locator is managing all the objects and it knows about all objects but no one else knows about the service locator. It's like a magic being that is responsible for creating objects and injecting dependencies. This is Dependency Injection. The holy grail. Finally you have made it so all objects are completely isolated from the init logic of each other. *cue the sound of angels singing*

You still haven't solved one problem. The logic of initializing the objects is still hard coded inside your DI framework. Well, you sprinkle IOC into Diand have all the information about initializing the objects in an XML file, and you have Spring 2...basically. Tada!! You extend this and make everything annotation driven, and you have Spring 3...basically.

Bras cause cancer. And tiny ads:
Java file APIs (DOC, XLS, PDF, and many more)
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!