Which below case will give me better performance
Using Spring Boot Autowired annotation for creating an object
Or
Using new key for creating an object.
I understand with spring annotations will have a choice of using lot more inbuilt features.
Kindly help me to understand
You need to learn an Inversion of Control pattern first of all: https://en.wikipedia.org/wiki/Inversion_of_control
Then you need to make yourself familiar with Spring Framework as an implementation of it: https://spring.io/projects/spring-framework
In two words answering your question: the Spring way with its dependency injection is much better by performance at runtime, then manual new managing. Just because Spring instantiates objects only once, at start up (mostly) and then provide you those ready objects. With new you have to manage then yourself and in most cases you lose with GC and memory (de)allocation.
Related
I'm new to spring 5 and my question is why does spring use DI and IOC? I mean why do we have to write the beans in an XML (legacy) and then create it where we need it? Why don't we use one method instead that gives us that object, until we want to use this complex mechanism that happens in the spring container?
And another question is, does not reading XML slow down the program? Because we are reading from the hard disk anyway.
Note: It is true that we can use annotations, but for now I want to ask a question about reading from xml.
Spring IoC Container is the core of Spring Framework. It creates the objects, configures and assembles their dependencies, manages their entire life cycle. The Container uses Dependency Injection(DI) to manage the components that make up the application. It gets the information about the objects from a configuration file(XML) or Java Code or Java Annotations and Java POJO class. These objects are called Beans. Since the Controlling of Java objects and their lifecycle is not done by the developers, hence the name Inversion Of Control.
More on link HERE
As for your first part of the question.
why does spring use DI
To allow the developer to keep his code loose, and not entagle classes, it keeps your code clean.
In object oriented design, the amount of coupling refers to how much the design of one class depends on the design of another class. In other words, how often do changes in class A force related changes in class B? Tight coupling means the two classes often change together, loose coupling means they are mostly independent. In general, loose coupling is recommended because it's easier to test and maintain.
You may find this paper by Martin Fowler (PDF) helpful.
I mean why do we have to write the beans in an XML (legacy) and then create it where we need it
Note: We write the bean in XML and it is created when application starts when it looks at bean defintion, techinally you are never creating a bean, you are fetching only created bean from Spring Container(IOC) that Spring created for you when you started your application.
We are writing bean blueprint, or just bean, so that it can be constructed, placed in the Spring Container when the application starts, and then we have it at our disposal that we can fetch it using getBean method.
The whole point of "why", is because by default all beans are scoped as singleton, that means, when you fetch a bean, and do with it whatever you want, you do not worry about memory or anything, Spring takes care of the beans for you if they are scoped as a Singleton.
Second question:
And another question is, does not reading XML slow down the program? Because we are reading from the hard disk anyway.
There is no difference in performance between annotation or XML, it is just a different approach, I am not sure what you mean by "reading from hard disk", but one way or another you will have to configure your application, yes, many forums prefer to run away from XML, but in my honest opinion the only reason for that is because when you write a bad configuration in XML it is lot harder to find it compared to configuration in Java that will throw an exception.
XML, application.properties files require a redeployment of the application, while annotation and java configuration require recompilation of your project, so both of them have "flaws", but it is normal and quite understandable to me.
But in the end I believe that it is a matter of preference, I know personally quite a few people that combine annotations with XML configuration and they know lot more about Spring compared to me.
So in summary, it is pain to write beans and their configuration, same as you can write a class with methods without creating an interface for it since the result will be the same, but it will help you in the long run since you do not have to worry about memory or if you destroyed that bean or if you did not.
It would be nice that you read about
1.Lazy initialization of beans
2.Eager initialization of beans
3.Singleton scope of beans
4.Prototype scope of beans
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
Say I have a file with each line depicting a different command (but of the same kind), which I want to read out and check and run and maybe do other operations such as merging, comparing and most importantly, store the commands into database.
To do that, I create the Command Class, and new a new Command object while reading each line of the file. Now the problem is, a Command object need to make use of, say a Spring bean which provides database access. As a result, I have to pass in that bean as a constructor argument of the Command class, which is very ugly, which doesn't seem to be the "Spring way"...
and I don't want to use ApplicationContextAware to make my class coupled to the Spring context.
Is there a best practice for this situation?
I very new to Spring and I know it might be a dumb question ...
I would create a CommandFactory that is coupled with spring and use that in your consumer instead. If the factory implements an interface you are not coupling yourself in the consumer and you don't close your possibilities of using a different -non spring coupled- one at a later point (e.g. testing).
In this case I think it is the best way to make the classes created by new Spring Beans.
Therefor annotate them with #Configurable, enable AspectJ, and read the Spring Reference Chapter 7.8.1 Using AspectJ to dependency inject domain objects with Spring
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.
I am starting to learn the Spring Framework. I came across this link but I can't understand in which order to learn from these?
Can anybody help me out?
The order of the entries on that page isn't organized so that you can gradually learn the concepts.
I'd rather advise you to try and go through the official Spring documentation first and take a look at the samples that come together with Spring. It'll give you an idea of the possibilities. Also, don't forget to make sure that you understand what the Inversion of Control (IoC) pattern is and why it's useful.
Here's what I'd recommend to someone starting out with Spring and IoC:
You should first try to use Spring in a very simple command-line application (hello world style).
Create an application context in xml and load it from your main method
Define a bean and retrieve it from your freshly loaded application context
Try to add a second bean definition in the application context and play with the bean definitions
Learn how to inject beans in properties, in constructors, ...
Play with those for a while in order to get a good feeling of what Spring core actually does for you (the IoC container) and how it can help you to decouple components in your code
Once you have a clear understanding of that, you can move on and read about Spring annotations and how you can either use xml or annotations (or even combine both approaches) to wire up your beans
You should only start using Spring in a Web application after having played around enough with the above. Once you have all that under control, then it'll be time to discover more advanced stuff and other Spring portfolio projects such as Spring Security, Spring MVC, Spring AOP, ...
The following are nice to have on the desk:
- Spring Configuration Refcard
- Spring Annotations Refcard
In any case, have fun! :)
I suggest you to learn from a books
I use Spring Recipes Second Edition to learn spring, the books is very technical and explain a good concept about spring