My Peers always force me to use Spring for creating new instance of any object. As per as my understanding, Spring provides a platform to manage the Business objects more efficiently. Spring makes the architecture more modular and more flexible.
There are some instances where I feel not to use spring bean, and go for general method of creating new objects. But, my peers always forces to do it by giving excuses of performance improvement. I never find any article related to spring where the factor of performance mentioned.
Question : If I am using spring beans for creating the object whether it improves the performance compare to creating new instances using "new" operator.
Spring Cons It requires a lot of expertise. If you have not used Spring before, first you will have to learn. The learning curve is also difficult, so if you have not a lot of development experience, it is difficult to learn. Parallel Mechanism: It provides multiple options to developers.
Spring Boot advantages include; No need for XML configuration, no need for WAR files, no need for POM, less source code, easy ember Tomcat, Jetty, etc.
Spring Boot is built on Spring. You can't use Spring Boot without Spring at all. However, you can choose your path of learning.
Spring is a tool like any other - when properly applied, it is a benefit. When improperly applied, it is nothing more than pure overhead.
This happens to be a common occurrence I see with Spring all the time - projects dictate that everything must be a Spring Bean. This results in a massive amount of overhead in terms of development artifacts when one is trying to do something simple.
The key point I see missed in many applications using Spring revolves around a general lack of object oriented experience or knowledge on the part of the designer/architect. They are comfortable with Spring, therefore everything must be Spring. This situation can often be identified by looking at the overall class hierarchy of the application (if you can - I don't know of any UML tool that understands Spring beans) - what you will generally find is an almost flat inheritance hierarchy - almost no classes will inherit functionality from a base class. This in turn implies very little to no encapsulation. This is turn will manifest as an extraordinary number of classes in the solution. Finally, in most cases I have seen, the applications which use Spring in this manner also have performance problems - not because of using Spring, but more from a lack of a comprehensive design. Spring is a framework, not an architecture.
The only area where Spring makes sense is for classes that are likely to change often or are tied to the execution environment - i.e. test vs production. Other than those areas, relationships between classes that exist in the problem domain (reality) should also exist in the code - these are not going to change and making them Spring beans simply adds overhead in terms of performance and development artifacts.
If your application is well architected, and in most cases, it probably is not, any library or framework would always be encapsulated by classes in the problem domain. This specifically means that the library or framework is not a visible component at the application level. This should be apparent to anyone with any OOA/OOD sense - can you think of a single problem domain in the business world that would formally include the ability to externally configure the relationships between classes. If you answer yes, then you do not understand OOA/OOD, and you would be one of those using Spring everywhere.
Here is a litmus test for you to see if you are overusing or incorrectly using Spring - could you, in theory, swap out Spring with something comparable without having to change your code? If not, then you have a weak design and are propping it up with Spring. This is most often identifiable if every release of your application increases your liability (increases your workload).
Finally, someone will chime in here with the "Spring makes testing easy" claim. That is true for most cases - most cases are part of poorly designed applications. The only thing that is even easier to test than an application built on Spring is an application that is built on a well designed object oriented architecture.
If you think rationally, how spring can be faster ? It's wrapper over your code. It also goes through the default constructor/overloaded constructor which ever is applicable.
e.g. import demo.dependency.injection.IAccount;
public class SavingAccount implements IAccount {
public static int SAVING_INT = 5;
public SavingAccount() {
System.out.println("Default constructor invoked!!");
}
@Override
public int calculateInterest(int amount, int duration) {
return (amount*duration*SAVING_INT)/100;
}
}
Bean configuration:
<!-- Fixed Account -->
<bean id="FixedAccount" class="demo.dependency.injection.impl.FixedAccount">
</bean>
When you load the bean using application context, it will print
ApplicationContext context = new FileSystemXmlApplicationContext("/Beans/SpringDemo.xml");
Account myAccount = (Account)context.getBean("FixedAccount");
Default constructor invoked!!
However, here we need to understand other than performance there are other advantages. like - DI - Manageability
So i think performance reason is not justifiable.
Apart from that: Spring IOC frameworks provide way to create instances using the spring bean configuration. However, it does not stop you to create instance using the new operator.
I would like to given an example where you may chose to use new instead of the spring bean.
Lets say in your web application you have singleton bean which has different methods for the business logic and in each operation you may need new object instances for operation (method level variable are thread safe).
Because if singleton bean has prototype bean then it will be invoked only once when singleton bean is invoked. Please go through this for complete understanding.
http://static.springsource.org/spring/docs/3.0.0.M3/spring-framework-reference/html/ch04s04.html
I think the only performance hit (how minor or major it could be) would be at startup time where the initial interpretation of the application context of Spring could slow it down. But after that since Spring has all its metadata at hand it should be now measurable overhead in the standard case.
So if your on the desktop where normally also startup performance matters it may impact the perceived performance in a large, complex applciation. With server-side applications it's mostly neglectable since the startup doesn't matter that much and it's more important how the application behaves under load.
The only other difference between Spring and non-Spring would be a partial impact on the default memory consumption since Spring needs to create and cache the metadata and AOP stuff in memory.
Spring framework is not for improving the performance of creating beans, instead it is for making the application loosely coupled. It uses Dependency Injection and Inversion of Control to achieve it.
Here is some articles telling you what spring can do?
If I am using spring beans for creating the object whether it improves the performance compare to creating new instances using "new" operator.
Normally No, it wont. Even spring needs either the constructor or reflection to create the bean. Since, by default spring beans are singletons so they are to be created only once. so accessing it for the second time might be faster. But make sure you are not using spring for only that.
While using spring, raw performance is not what comes to mind while creating apps. It is the maintainability of the code as it grows. You are therefore advised to use Factory methods to instantiate objects as they separate you from the burden of creating & maintaining objects to execute your business code. IOC being the core tenet of spring, helps you in creation of objects without your involvement. For a best practices artile, you could look at this blog post.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With