Spring Beans Life

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 set开发者_StackOverflow中文版ters 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,

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.

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.

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.

after you declared your beans an XML file or provide them as Annotations for the Framework to understand what it should do.

Book: Just Spring