What is the core of spring? The real purpose of why it came to being and is so popular. Most Java/J2EE application code tend to become monolithic (read a single large code base) over time - i.e. the application code slowly diminishes to maintain its modularized form with the result that the dependency relation graph between the classes/objects gets really ugly with no standard form. Secondly the applications also need a lot of infrastructure services - like Life Cycle Management of their objects and important resources like database connections etc, Database Access, Transaction Management and many more.Even simple Java applications would at least require efficient management of their objects and its dependencies. Although standard J2EE API and the application servers implementing those API claim to provide all the infrastructure services, applications still tend to become monolithic and unwieldy. So we need simplicity and freedom in the following areas:
1. Externally configurable objects - It is always better to be able to configure objects externally, i.e. set their values externally without recompilation of Java code or involving developers. The whole beauty of the general concept of configuration is that any change made to it does not require a rebuild or redeployment.
2. Simple POJO based programming - If we are just able to concentrate on programming business logic and not spend time of writing infrastructural code, we speed up the time to deliver the project by at least 40%. Simplicity and speed usually are natural if we adopt the POJO-based programming model. But for a real application, we have to add code to the POJOs to access databases, coordinate transactions, locate services provided by the container/environment, and so on. We would like these tasks to be performed declaratively via configuration (and via annotations), without disturbing the POJO code.
3. Dependency Resolution - Java interfaces do provide a clear separation between a contract and implementation. Ideally we would want the client class to be dependent only on the interface class. But we still have to look up the implementation class that we want to use. If it is hard-coded in Java code, we lose the advantage of interfaces, because the client class now depends on the interface class and the implementation class. Eg. Let's say we have an interface I and 2 concrete implementations of it - say C1 and C2. The whole idea of having interface is to shield client from the concrete classes at compile-time. But the client class still had to know about C1 at compile-time. But the client class still ends up having something like this:
4. Lookup of Resources - A Java object A, say, depending on another Java resource B or a resource like Database C, should not be concerned with looking up for them. We again need a way to externally configure lookup code. So how does Spring help us?
1. Externally configurable objects - It is always better to be able to configure objects externally, i.e. set their values externally without recompilation of Java code or involving developers. The whole beauty of the general concept of configuration is that any change made to it does not require a rebuild or redeployment.
2. Simple POJO based programming - If we are just able to concentrate on programming business logic and not spend time of writing infrastructural code, we speed up the time to deliver the project by at least 40%. Simplicity and speed usually are natural if we adopt the POJO-based programming model. But for a real application, we have to add code to the POJOs to access databases, coordinate transactions, locate services provided by the container/environment, and so on. We would like these tasks to be performed declaratively via configuration (and via annotations), without disturbing the POJO code.
3. Dependency Resolution - Java interfaces do provide a clear separation between a contract and implementation. Ideally we would want the client class to be dependent only on the interface class. But we still have to look up the implementation class that we want to use. If it is hard-coded in Java code, we lose the advantage of interfaces, because the client class now depends on the interface class and the implementation class. Eg. Let's say we have an interface I and 2 concrete implementations of it - say C1 and C2. The whole idea of having interface is to shield client from the concrete classes at compile-time. But the client class still had to know about C1 at compile-time. But the client class still ends up having something like this:
I iobj1 = new C1(); iobj1.executeMethod();We do have to be aware of C1, otherwise we would never be able to work without real implementations. But it is better to have awareness outside of Java code.
4. Lookup of Resources - A Java object A, say, depending on another Java resource B or a resource like Database C, should not be concerned with looking up for them. We again need a way to externally configure lookup code. So how does Spring help us?
- Spring helps us achieve the above by wiring the dependencies between objects, all external to Java code.
- Spring is essentially a technology dedicated to enabling you to build applications using POJOs.The components/objects are simple POJOs providing simple getters and setters. The container wires all the objects passing the dependent objects to POJO properties or constructors.Spring achieves the above using the Dependency Injection mechanism.
- Most importantly, Spring itself is modular and has a layered architecture. This means we can use just the core JavaBeans configuration management without using the MVC framework or AOP support or DAO support. This means we can create modularized applications of any kind; so you are not restricted to creating web-based enterprise Java applications.
5 comments:
So Spring = DI ?
I've been using Spring and JEE (not J2EE) for some time and personally find nothing wrong with JEE. Spring is helpful in many areas but today JEE is quite easy and simple. What to use really depends on type of solution to implement.
The spring guys deserve great kudos and respect for pulling the JEE world out of the ejb2 debacle.
However I think they are drinking too much of their own cool-aid at the moment as they reinvent the world under the Spring source brand. Stay tuned for SpringCobol coming to a site near you soon.
Guice is much better and written by people who eat their own dogfood.
Use spring if you like writing tons of xml and debugging strings in those files.
I couldn't recommend spring to anyone. At all. In any circumstance.
Thanks for your suggestions. So Guice is one more Dependency Injection framework by none other than Google. I would have to look into that. My main objective of this post was to present to people (newbies especially) what Spring is really about. Because it is very easy to be lost in all the sea of features that Spring provides. Most of the articles and Spring documentation is also targeted towards the more experienced Java developer.
Spring Framework is much more then just DI. But the core of Spring is.
This tutorial does explain what Spring tries to solve in JEE applications, but it doesn't give examples what happens if you don't use a factory or dependency injection.
The biggest problems come from inflexibility and the inability to test your code.
For some solid examples, check my write-up on the patterns behind this populair framework here.
Post a Comment