When (not) to Use the Java Enterprise Frameworks
The first advice is that one should not add Spring, EJB, Struts, Rule Manager or any other framework until convinced. Every Java/JEE project has its own needs. By adding the latest framework or third party tool one may be able to boast of using the latest technology in the project but the results may not be what the customer expected.
Moreover, the time and budget constraints play a crucial role in deciding what framework to use. If you have ample time then you can keep on looking for tools which can perform your task much easier but even then performance should be taken into consideration.
Spring is the latest buzz word in the Java enterprise applications. Almost every requirement that we see posted on job portals requires experience in Spring. Of course, Spring can make an application easier to code and also bring in more maintainability but it will affect the performance.
If I have say a log analyser application wherein I need to parse the log file and display where piece of information in the graphical format. This kind of application does not have any enterprise requirements like Transaction management, Security, Multi-threading or life-cycle management. So it does not make sense to include the Spring or EJB in this kind of application.
Though it is true that Spring brings in loose coupling between the classes which is required for maintaining the application. But coupling between classes can be handled without any framework to some level. It’s when the application grows to a level that there are 100 classes, the need for framework arises.
So it is always advised by the Java Gurus to judge the requirement before going in to choose a particular framework. Pick the framework which suits your application requirements and not just the latest in the market.
The first advice is that one should not add Spring, EJB, Struts, Rule Manager or any other framework until convinced. Every Java/JEE project has its own needs. By adding the latest framework or third party tool one may be able to boast of using the latest technology in the project but the results may not be what the customer expected.
Moreover, the time and budget constraints play a crucial role in deciding what framework to use. If you have ample time then you can keep on looking for tools which can perform your task much easier but even then performance should be taken into consideration.
Spring is the latest buzz word in the Java enterprise applications. Almost every requirement that we see posted on job portals requires experience in Spring. Of course, Spring can make an application easier to code and also bring in more maintainability but it will affect the performance.
If I have say a log analyser application wherein I need to parse the log file and display where piece of information in the graphical format. This kind of application does not have any enterprise requirements like Transaction management, Security, Multi-threading or life-cycle management. So it does not make sense to include the Spring or EJB in this kind of application.
Though it is true that Spring brings in loose coupling between the classes which is required for maintaining the application. But coupling between classes can be handled without any framework to some level. It’s when the application grows to a level that there are 100 classes, the need for framework arises.
So it is always advised by the Java Gurus to judge the requirement before going in to choose a particular framework. Pick the framework which suits your application requirements and not just the latest in the market.
An application which will generate DAO and DTO for another application is not a good candidate for enterprise frameworks like Spring and EJB. But an application which manages the identities of users on applications like Lotus Notes, PeopleSoft or SAP is a good candidate for the enterprise frameworks.
A good example will be if the application requires good performance, security but doesn't require services like thread management or lifecycle management then one can consider using PL/SQL procedures and LDAP for its requirements instead of not using the extra services which will be overhead when an framework is used.
The common factors to be considered before deciding the framework for an application are:
1) Do you want to have transaction to be managed? This is meaningful in case you have lot of database READ and UPDATE operations
2) Do your users invoke the application at same time?
3) Do you see the number of users increasing in the future?
4) What is the number of classes in your application?
5) Is your application more of a utility application than an enterprise application?
I don't think Spring is the latest buzzword, it's been around for years, but I do agree that it would be foolish to use it in a small desktop application.
ReplyDeleteby the way what's the latest java based framework ? Spring is most popular now days but yes its around from some years .
ReplyDeleteJavin
How to check if a thread holds lock on a particular object in Java
How exactly does Spring affect performance? In the simplest form, Spring is just a DI framework, and once the classes are wired, there's very little run time performance hit. Plus, Spring or Guice can be used for very small, non-web projects to add DI. Any code that's going to be used for real business and lasts longer than about 7 seconds for the lifetime of the project would benefit from good design. Maybe the real question is, how small does an application have to be to benefit from good design? Obviously all applications destined for any kind of business operation should be well designed.
ReplyDelete1) "But coupling between classes can be handled without any framework to some level" - would tell - without any framework better than with any framework.
ReplyDelete2) Spring is not JEE - not mentioned by Oracle in Java EE 6 list.
Sandeep, can you please explain how exactly spring effects performance ..than other application frameworks
ReplyDeleteIf it os " foolish to use" a framework in a small application how can that be not fulsh for a big one? Compare to HybridJava.
ReplyDeleteBuilding a skyscraper requires different tools than building a dog house. Dependency injection can easily be done manually in a small project, but becomes a burden in large ones. Enterprise applications benefit from things like Spring, Guice or CDI, whereas using those tools to write a notepad would be like using a power drill to punch holes in paper. It can be done, but it's - "foolish".
ReplyDeleteGuys, I am not against Spring. It is one of the wonderful innovation in the programming world.
ReplyDeleteSpring or any other framework is costing you extra processing.
1) Spring will have extra parsing of xml's/annotations (even with DI than using the new operator).
2) EJB will make me use application server.
3) Business Rule Management Systems like JRules or Drools will make me vendor dependent.
4) PL/SQL procedures may not give me too much flexibility and maintainability.
I think developers treat Spring as free of any kind of processing because they don't see the need of application server as with EJB.
But be it any framework. It will add some processing and will also give you some benefits.
Suppose I want to have MVC pattern in my application. I can use Struts2, Spring MVC or any other MVC framework.
But then the question is, what is my application's requirement?
If you use ONLY the DI part of Spring (in an application where it makes sense), you won't see much of a runtime hit. Your application will take a bit longer to start up, but then Spring will be out of your way. On the other hand, DI is extremely simple to implement, so maybe Spring isn't worth using solely for DI.
ReplyDeleteIf you use the other parts of Spring, your application's runtime performance will be very slow and you'll be stuck with a dependency on Spring that will be very difficult for you to break.
The reason Spring became popular is because you can have unskilled developers write the "easy" parts of your application (the business logic... which often is actually the hardest part) and have a functioning (even if poorly-designed/coded) application at the end of the cycle. If your developers are actually really good, then you should theoretically end up with a really excellent application in less time than it would take to write ALL the code from scratch (though if your developers ARE actually really good, they probably don't use Spring, and I personally find it much faster to just write it all myself than try to make sense of Spring's unnecessary complexity). My personal experiences with people who strongly advocate Spring is that they tend to be stuck at being (at best) average-skilled developers. They've stopped learning and think everything is "too hard" if Spring doesn't do it for them.
One of the big problems with Spring is that if you use even one thing it provides beyond the DI bits, you become entirely dependent on Spring much like how a single use of heroin makes you physically addicted. And, like heroin, breaking your dependency on Spring becomes more difficult the longer you use it. People who use Spring stop thinking for themselves, because "Spring does that for me." Spring users try to force EVERYTHING to fit Spring instead of asking if Spring fits the application's requirements. Whenever some new feature is added to the Spring framework, Spring's addicts start desperately looking for ANY way they can to use that new feature, even though it may provide absolutely no benefit to their application. Generally speaking, new "features" added to Spring are based not on sound engineering principles or actual usefulness but on whatever the latest buzzword/fad is. Spring is great for winning buzzword contests.
Another problem Spring has, and possibly its biggest problem, is that it tries to be all things to all people. Everyone knows that the jack of all trades is master of none, and that holds true for Spring. It tries so hard to be able to do absolutely everything you could possibly want, that it isn't very good at any of it. The ONE thing the Spring developers almost did right from a technical perspective was making Spring modular, which worked in the early days of Spring. Unfortunately, new Spring features are built on top of other Spring features (and rather poorly, at that), so you can no longer just pull in the ONE piece you want to use without also pulling in much of the rest of the framework, which bloats your application and slows down your runtime performance.
If, like most of today's "web-scale" applications, your application needs to run fast, you should not use Spring. If you need your application to be simple, you should not use Spring. If you have a desire to learn new techniques and grow and improve your skill as a developer, you should not use Spring. It's just a lot of very well marketed hype without any real payoff.