I am reading spring docs this site.
and I already have knowledge IoC(or DI) and AOP a little bit.
While reading docs, I read this phrase.
Foremost amongst these is the Spring Framework’s Inversion of Control (IoC) container. A thorough treatment of the Spring Framework’s IoC container is closely followed by comprehensive coverage of Spring’s Aspect-Oriented Programming (AOP) technologies.
As far as I know, IoC is how Container creates instances and injects them when needed, and AOP is perspective-oriented programming;How you can focus on what you want to do.
However, I understand the above phrase that AOP works well thanks to IoC.
I'm not sure what's the relationship between the two.
Wait for a good answer.
An IoC framework allows injection of an implementation through an external influence, typically configuration.
AOP's purpose is to enable loose weaving of other concerns into business logic code without direct modification of the code.
Spring is a framework that extensively uses AOP to enable implementation of IoC.
There is a whole lot of reading material on both patterns available on the web.
For IoC start here. For AOP, I found this helpful.
AOP concerned mainly with abstracting functionality that applies across the board to many components of your application. for example logging and security. These have little or nothing to do with actual business functionality but are essential system-wide functions
IOC or Di is mainly loose coupling and managing the dependencies between the component of an application.
Both IOC and AOP are made possible through having your code managed by some sort of run-time container.
The container injects dependencies into your constructors and property setters, instead of you doing it manually. The motto for Spring is/was: "Creating objects so you don't have to."
Once your code is running in a container, it's a simple enough matter to introduce AOP concepts which boil down to executing code before or after what's being managed by the container.
IOC and AOP are sibling practices made possible by a run-time container. Start with a IOC container and it's easy to introduce AOP features. Start with an AOP container and IOC features easily follow.
Related
What the terms added into the AOP, so that we are calling it Cross Cutting Concern.
Difference between Interceptor and AOP.
-This question is for lil bit discussion on AOP and Interceptor but please elobarate.
Interceptors are part of Spring framework which allow you to write logic by intercepting requests/calls in between the route. There are mainly 2 kinds of Interceptors in Spring.
Handler Interceptors, present in Spring MVC framework, are used to include your interceptor logic for web requests, whereas Method Interceptors, within Spring AOP framework, are generic in nature and not just limited to intercept HTTP requests.
When comparing AOP with Interceptors, I can say, in one line, that these Method Interceptors are the base understanding behind writing aspects in AOP.
AOP, aka Aspect Oriented Programing, is a bit complex subject to be explained in a StackOverflow answer. I would suggest you to read for it on internet and make yourself comfortable with the basics & AOP terminology before entering into Aspect Oriented Programing.
Below is one good resource to understand the dynamic proxy in Spring AOP and fundamentals of it.
Understanding Dynamic Proxy: Spring AOP Basics
Update
Wikipedia has a very simple yet effective definition & example for Cross-Cutting Concern.
In Aspect-oriented software development, cross-cutting concerns are
aspects of a program that affect other concerns. These concerns often
cannot be cleanly decomposed from the rest of the system in both the
design and implementation, and can result in either scattering (code
duplication), tangling (significant dependencies between systems), or
both.
For instance, if writing an application for handling medical records,
the indexing of such records is a core concern, while logging a
history of changes to the record database or user database, or an
authentication system, would be cross-cutting concerns since they
touch more parts of the program.
AOP with Spring Framework is described in a very simple manner at this article of TutorialsPoint which would help you get familiar with all the basic terminologies of Spring AOP.
What is the Difference between Spring IOC and Spring AOP and their Importance ?
Have you searched the web for IoC and AOP? There are a lot of references to both.
In a nutshell, IoC allows an external force to determine what implementation will be used by code rather than the code determining the implementation. The "external force" might be a configuration file, a unit test, other different code, etc.
AOP allows cross-cutting concerns to be implemented outside of the code affected by those concerns.
The "purpose" of Spring includes IoC and AOP, but goes quite a ways beyond that in its scope.
For more details please check.
Inversion of Control Containers and the Dependency Injection pattern and
Aspect-oriented programming
Also check this
What is AOP, Dependency Injection and Inversion Of Control in Simple English
IoC, AOP and more
Spring IOC: In simple answer normally you create object with new operator and set yourself for getter and setter. So, yes we use new operator in Java to create object. There is no any bad in doing this. But, when your project size grows and lots of developers are working, and you want to achieve POJO-based programming, you can use DI. So then maybe your question arises - why I can not code it myself? Of course you can use the power of reflection, annotation, and XML. But, some other had already coded this then why not reuse the third party one? There are lots of options for you to choose; Spring can be the best one. It manages your object life cycle from object creation to its destruction. You use the objects created and set by Spring DI container but you do not create them yourself.
Spring AOP: It is related to cross cutting concern. What it mean is in large system the common functionality is scattered throughout different modules. So AOP provides an easiest way to take out a common implementation in the form of 'aspect'. You can also in this case write own implementation using proxy concept but you can reuse the code of proxy based that is implementation of APO alliance using Spring.
Objective of Spring IOC is to reduce explicit dependencies between components, while purpose of Spring AOP is to wire components together possibly by enforcing certain common behavior (read: NOT Interface)
Since purpose of Spring AOP is to enforce certain behavior across components.So, Spring IOC comes in handy to achieve this purpose
All websites state that the Spring core container is the basis for complete Spring framework i.e., it is used across
the all modules like AOP, JDBC module, Web module, etc. As per my understanding, the Spring core container's main purpose is
to inject dependencies, so avoiding the need of factory classes and methods. Is that correct?
Second question: When it is said, Spring core container is the basis for complete Spring framework (e.g., for Spring AOP). As per my understanding, in Spring AOP also, getting the object of classes like
ProxyFactoryBean is achieved by core container. Right?
Thirdly, it is stated that Spring core container avoids the need for programming the use of singletons. How come singleton
classes are avoided by core container?
yep
yep
All beans declared in Spring config files are singleton by default. They are instantiated when your application starts.
First off, your understanding of what you get from Spring is about right. So let's get on to your third question, the interesting one.
The key is it's not that you don't have singletons, it's that they're singletons by configuration. This is a vital difference, as it means you can avoid all the complicated singleton enforcement code (the source of frequent problems) and instead just write exceptionally simple programs that focus on the business end of things. This is particularly important when you are writing a program with non-trivial object lifetimes: for example, in a webapp it makes it very easy to manage the lifespan of objects that hold state associated with a user's session, since if the objects have session scope, they'll be “singleton per user session”. That's enormously easier to work with than many of the alternatives.
The fact that Spring can also help out with transactions is just perfect as transaction handling is distinctly non-trivial, and AOP is the best solution to them in Java that I've seen (other languages have other options open) with Spring supporting a pretty straight-forward way of doing it. Try to do it properly without if you don't believe me. Spring's pretty much wonderful.
How is it correct:
"Spring is in general a container, which manages objects..."
or
"Spring uses/contains a container, which manages objects...."
I mean, the IoC Container is PART of the Spring Framework, right? Or could you say, Spring IS a container?
Thanks :-)
[Spring Framework 3.0.5]
Spring is a Framework that follows the Inversion of Control paradigm. Inversion of Control is a principle (the implementation details do not matter) -- the "inversion" is when you wire up your beans outside of the code, in the configuration. There are many ways to do that. An analogy would be Object Oriented programming. Object Oriented is a paradigm, just like IoC, with many ways to do it. Just like with OO, there are details that you should know, but the paradigm exists at a higher level.
Spring is a Framework because it includes a lot of libraries to make your life easier. Here the details matter; you need to know how JmsTemplate or the TransactionTemplate work to use them.
Your question is primarily about the best words to use when describing Spring, which is a valuable question. Now look at this picture, taken from here.
First, the high level words include FRAMEWORK. There is also a logical part of the application called the container, that is further divided into its components. The documentation for the container is here. When people talk about Spring, they primarily say its a framework and an IoC container, depending on how they use it. Perhaps it is accurate to say Spring is a Framework that includes an IoC container.
The important thing is you can use parts of the Spring Framework that have nothing to do with IoC , just the IoC part, or both.
I am trying to understand Spring. I have read about it and done some tutorials. I kind of get the IoC paradigm and the fact that DI is its implementation in Spring.
My question is this: What do you lose by not using Spring? I understand this is a big question and somewhat subjective. But if you could write a few dot points or give an example of a problem that could occur if Spring was not used, I think that would help me and many other people.
Spring is far more than just another IoC tool (think of DAO related stuffs, convenient MVC support, testing tools, ...). In my opinion, it has gradually grown to a kind of "flavor" of Java. But that's not the point :)
Speaking of IoC/DI, what you loose not using it is the easiest way to gain loose coupling in your application, that is associated to reusability. Obviously, most of people tend to think of reusability of a component in another project, which, in my experience, occurs not that often. Greatest benefit of reusability appears when you have to unittest your code.
Programming through interface and using DI/IoC make unittests so easy that even those who are reluctant to unit test will start loving it.
Loose coupling and benefit in matter of UT is one thing you'll lose.
There are no problems actually. But if you start writing your code you will end up with a homegrown framework much like Spring. The thing you get with using Spring is that the framework is already more generic (than your own) and you can use it in a lot of different projects. And the most important (maybe) is that Spring is well tested with so many users using it.
Of course you can try also another framework not just Spring. There are a lots out there...
I did a write-up on why people use dependency injection frameworks (like Spring and Google Guice). Most tutorials neglect this, but IMHO it is the most important thing.
If you understand the problem you have, and what problems all these patterns/frameworks solve, only then are you able to make good software and great architectural choices.
Read about it here: http://www.redcode.nl/blog/2010/01/dependency-injection-dissection
Put simply, you apply dependency injection to write clean and testable code. Also in return you achieve a design in which the caller knows which implementation to use(inject) rather than callee (this is what's famous as the "Hollywood principle"). Now if you don't use use DI frameworks like Spring and Guice you try to achieve dependency injection using factories. But factories come with a cost of boilerplate code and uneasy clean-up while testing. Some people also find other strengths in these frameworks which is their easy integration with frameworks belonging to different tiers like Struts, Hibernate etcetera.
A glib answer is that you'd have to code it all yourself. I don't know much about Spring (yet), but even the basic act of constructor injection would require a lot of code whereas with Spring you need two edit points:
In config:
<sectionGroup name="spring">
<section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core"/>
<section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />
</sectionGroup>
<spring>
<context>
<resource uri="config://spring/objects"/>
</context>
<objects xmlns="http://www.springframework.net">
<object name="mediaLibrary" type="AlbumLibraryWPF.AlbumLibrary, AlbumLibrary"/>
</objects>
</spring>
In code:
IApplicationContext ctx = ContextRegistry.GetContext();
library = (Library)ctx.GetObject("mediaLibrary");
Which would you rather do: write a DI framework yourself or concentrate of building your solution?
Spring is much more than a DI framework. There a lot of areas that it will make programming easier for you:
JDBC, Hibernate, JMS templates (dramatically reduce code line count)
Aspect programming
Security (Spring security)
Spring MVC
Spring Web Services
These are just some examples - there are many more. You don't have to use any of the above, but there all part of a mature, well designed framework and in general they make things easier.
The core of Spring is of course Dependency Injection. The benefits of using a DI framework may not be apparent for small projects, but there are more than evident for large and complicated ones. Martin Fowler explains Inversion of Control very clearly. Of course there other alternatives (Guice for example), but I would say that Spring is now an industry standard.
IoC is mostly a good thing within the Java language because when most applications start growing and you don't design for modularization/loose coupling, you end up with a big pile of interconnected classes without no sensible boundaries.
For starters, Spring and other IoC/DI frameworks makes you think about modularization right from the start. This is big because if you have your code well modularized/loose coupled, you end up componentizing and reusing much more wich leads to better unit testing (if you do unit testing anyway).
If I want to write a DAO, I can define its interface up front:
interface IPersonDao {
List<Person> getPersonsByTeam(String teamName);
}
then, I can just call for the implementation of this interface from anywhere in the src where's Spring is being "applied". Suppose i need it in a service layer:
class MyService {
#Autowired
IPersonDao svc;
}
or in a test class:
class TestPersonDao {
#Autowired
IPersonDao svc;
#Test
void testGetPersons(){
List<Person> persons = svc.getPersonsByTeam("billing");
Assert.assertDataSet(persons, "billing.xml");
}
}
Besides, my Dao implementation can hide the complexities of data access without messing with the Dao contract. If I require a hibernate session or a persistence manager, I just declare that:
class JpaPersonDao implements IPersonDao {
#PersistenceContext
EntityManager em;
List<Person> getPersonsByTeam(String tm) {
em.createQuery("...");
}
}
Componentization of classes requires a registry in order to wire collaborating beans. This could be developed by hand, but there are already DI frameworks that do this. Besides, Spring has alot of other stuff like exception translation, support for aspect programming, mvc frameworks, portlet frameworks, integration with hibernate, jpa and/or other db stacks which of course integrate nicely with the Spring IoC stuff.