Take the 2-minute tour ×

I am trying to understand programming logic behind the beans of Spring. In examples it is often given them a concrete name like "Duke" or "Kenny", moreover concrete values also given for constructors and setters which are injected in xml. I think about beans in more general way, say:

Student basicStudent = new Student(grade, name); // gives me certain amount of flexibility where say for grade and name I can have different values, then I can deploy this new student to database. And every unique web request, lets say, I can recreate various instances of different students with this line. 

But with .xml what do I do? I retrieve static bean with predefined values:

Student Bob= (Student)appContext.getBean("Bob"); // where this bean is set with predefined values

Hopefully my confusion will be understood, I can't think of application of Spring Beans. I am not production developer , just a student, so I may miss some important concept in here. Why would I need preloaded beans with unique instance of a class?

Thank You,

share|improve this question

3 Answers 3

up vote 1 down vote accepted

Spring is generally a framework to support enterprise development, which almost always means some kind of web application (GUI or API) with some business logic embedded. If you were to write even a trivial Java web application and give it some meaningful structure--meaning your code isn't all packed into one, massive class with no division of responsibility--you'll quickly begin to run into questions like, "Who/what should be responsible for creating instances of these classes?" and, "How do the instances get ahold of other instances (dependencies) that they need?" These questions lead naturally into the need for a Dependency Injection/Inversion of Control container, which Spring is.

Further, if you're practicing test-driven development, which there's no excuse for any new developer not to be practicing, you'll find further tension in the "getting dependencies" question, as an object that creates its own dependencies internally is very difficult to test as compared to an object that allows its dependencies to be injected.

This can only be the barest beginning of an answer, but let me know if it helps and if there's something else that I can clarify.

Update: Regarding your question of creating beans to represent each Student: That's not quite the way that Spring--or Dependency Injection containers in general--are intended to be used. You wouldn't write an XML bean definition for every single Student in your app. There's a sometimes-fuzzy line between different "kinds" of objects.

There are objects that hold distinct state that differentiate them from other objects of the same type. We tend to call this type of object an "entity" or "domain object". Your Student and Teacher are perfect examples. Each instance of those objects would represent a specific person.

The other kind of object is the kind that has no distinct state that differentiates it from other objects of the same type. More importantly, it has no state with respect to any specific entity instance. An example of this might be a Data Access Object (DAO), which encapsulates and hides the complexity of interacting with a relational database. It has state, like a connection pool that it draws database connections from in order to do its work, but whether you have one instance of the DAO or 100, they're all identical and interchangeable.

We always use Spring to manage the latter category of objects--the ones that are stateless with respect to the other objects that they interact with. Typically, we just create one of each (scope="singleton", which is the Spring default), and let Spring wire them all together so that all dependencies are filled.

For the other category--the entities--some people use Spring to inject dependencies into them, and some don't. Nobody explicitly creates each of their entity objects as a Spring bean in an XML file, though. Entities are always created using the new operator, whether by you or by some other framework that's handling them for you. There are other ways of letting Spring manage an object, though. For example, using AspectJ, you can weave bytecode in such a way that when you invoke a constructor (like with new Student()), not only is the instance created, but Spring performs dependency injection on it as well. This is more the style of DI that you would use with an entity.

share|improve this answer
That is exactly what I wanted to hear, thank you. I will formulate my questions if you'd have time to answer them please, it is just too much information for me at the moment I need to process it :-) –  Aubergine Aug 8 '11 at 17:34
If we could consider it even with DAO, there is Student and there is Teacher. I would want to avoid creating new Teacher() in Student, but also don't want to define 100 beans with IDS (id="bob", id="mark") ref to single teacher, is Spring capable of resolving this ? Or my example is still out of context? I understand this underline substitution process and already set up some basic projects using DI, but what I want to have maybe very basic real life example, but not with factories as it would kill me definitely, so I would finally have click in my head , not greasy mass of data. –  Aubergine Aug 8 '11 at 17:47
@Aubergine: Added to my answer. See if that clears it up. –  Ryan Stewart Aug 8 '11 at 21:35
Thank you, I've wrote these DAO entities, but only now I find out what are they called(modern education) . Now everything makes sense. So the dependency injection is basically object Setter for another object + programming with interfaces. Spring application context serves as a repository where we contain only, say "persistent" entities and wire them together. So for now to be it easier for me I have to think about entities which are created once and are used through out the life cycle of a program, if I have those I use Spring container to handle them. –  Aubergine Aug 9 '11 at 14:15
@Aubergine: Yes, it sounds like you've got the right idea. When we say "persistent entities", though, we're talking about the entities that I mentioned, and specifically we're talking about ones that are "persisted", or stored in a database, so be careful how you use that term. –  Ryan Stewart Aug 9 '11 at 16:22

I think your confusion is around the difference between Java beans and Spring beans. Spring beans are Java beans, but the kind of beans Spring usually manages are at a higher level.

A Student class is a Java bean that might be used as a 'data object' (DAO) in an application. They would be created at runtime from user input, database access, reading from a file, etc. The class that is used to create these Student objects is a better candidate for a Spring bean - this would be a 'StudentFactory' in the usual design pattern naming scheme.

Having the StudentFactory bean managed by Spring means that the method for generating Students is configurable. For production, you could have a DBStudentFactory that reads from a database. For testing, you could have a TestStudent factory that just loads a Map.

share|improve this answer
Thanks a lot, that doesn't sound very exciting though - except for really large applications? –  Aubergine Aug 8 '11 at 17:14
The accepted answer sums up why you would want DI on any sized project. On really small projects you may not need Spring, just programming in a DI style may be enough. –  AngerClown Aug 8 '11 at 18:16

There are many advantages of using beans.

  1. You have an IOC container: http://en.wikipedia.org/wiki/Inversion_of_Control
  2. An IoC container saves a ton of time eliminating simple tasks such as setting a datasource for database access. The datasource can be injected automatically
  3. Testing is easier since you can uncouple objects without much effort.
share|improve this answer

Your Answer


