The Spring Framework is an open resource application framework that intends to make J2EE development simpler. Unlike single-tier structures, such as Struts or Hibernate, Spring intends to provide a structure for whole applications in a regular, productive way, pulling together best-of-breed single-tier frameworks to provide the best architecture.
Issues with J2EE
Considering that the widespread implementation of J2EE applications in 1999/2000, J2EE has actually not been an unqualified success. While it has actually brought a standardization to core middle-tier concepts such as transaction management, numerous– perhaps most– J2EE applications are over-complex, take excessive effort to develop, and shows disappointing performance. While Spring applies in a vast array of environments– not just server-side J2EE applications– the original inspiration for Spring was the J2EE environment, and Spring provides numerous valuable services for use in J2EE applications.
The extensive usage has highlighted particular causes of complexity and other problems in J2EE applications, such as:
- J2EE applications tend to consist of extreme amounts of “plumbing” code. Several code reviews repeatedly reveal a strong proportion of code that doesn’t do anything: JNDI lookup code, Transfer Objects, try/catch obstructs to acquire and release JDBC resources … Writing and maintaining such plumbing code proves a major drain on resources that should be concentrated on the application’s business domain name.
- Several J2EE applications use a dispersed object design where this is improper. This is one of the significant reasons of excessive code and code duplication. It’s also conceptually wrong in most cases; internally distributed applications are more complex compared to co-located applications, and frequently much less performant. Naturally, if your business demands dictate a distributed architecture, you need to implement a distributed architecture and accept the trade-off that incurs (and Spring offers features to assist in such scenarios). But you should not doing this without a compelling factor.
- The EJB part design is unduly complex. EJB was conceived as a means of minimizing complexity when implementing business logic in J2EE applications; it has not succeeded in this aim in method.
- EJB is overused. EJB was basically designed for inside distributed, transactional applications. While almost all non-trivial applications are transactional, distribution should not be built into the fundamental part version.
- Many “J2EE design patterns” are not, in fact, design patterns, but workarounds for technology limitations. Overuse of distribution, and use of complex APIs such as EJB, have created many questionable design patterns; it’s important to examine these seriously and seek less complex, much more effective, methods.
- J2EE applications are tough to unit test. The J2EE APIs, and specifically, the EJB component model, were defined before the agile movement removed. Therefore their design does not take into account convenience of system testing. Through both APIs and implied agreements, it is remarkably difficult to test applications based upon EJB and many other J2EE APIs outside an application server. Yet unit testing outside an application server is essential to achieve high test coverage and to reproduce many failure scenarios, such as loss of connectivity to a database. It is likewise vital to ensuring that tests could be run quickly during the development or maintenance process, minimizing unproductive time waiting for redeployment.
- Certain J2EE technologies have simply failed. The main offender here is entity beans, which have proven little short of tragic for productivity and in their restrictions on object positioning.
The traditional response to these problems has actually been to wait for tool support to apprehend up with the J2EE specifications, meaning that developers don’t need to wrestle with the complexity noted above. However, this has largely failed. Tools based on code generation techniques have not delivered the yearned benefits, and have displayed a number of issues of their own. In this approach, you might generate all those verbose JNDI lookups, Transfer Objects, and try/catch blocks.
Generally the experiences have shown that frameworks are much better than tool-enabled code generation. An excellent framework is normally far more flexible at runtime compared to produced code; it should be possible to configure the behavior of one piece of code in the framework, instead of alter several produced courses. Code generation also poses problems for round-tripping oftentimes. A well-conceived framework could also provide a meaningful abstraction, whereas code generation is generally simply a faster way that falls short to conceal underlying complexities during the entire project lifecycle. (Frequently complexities will reappear damagingly during maintenance and troubleshooting.).
A framework-based approach recognizes the fact that there is a missing out on piece in the J2EE jigsaw: the application developer’s view. Much of what J2EE provides, such as JNDI, is simply as well low level to be a day-to-day component of programmer’s activities. In fact, the J2EE specifications and APIs can be judged as far more successful, if one takes the view that they do not offer the developer a programming model so much as give a strong basis on which that programming version should sit. Good frameworks supply this missing out on piece and offer application programmers a basic, productive, abstraction, without giving up the core capacity of the platform.
Identifying the relevance of frameworks to effective J2EE tasks, many programmers and companies have actually attempted to compose their own structures, with differing degrees of success. In a minority of instances, the structures attained their desired goals and significantly cut costs and improved efficiency. In most cases, however, the cost of developing and keeping a framework itself came to be a concern, and framework design flaws emerged. As the core issues are universal, it’s much preferable to work with a solitary, widely made use of (and tested) framework, instead of implement one in house. No matter how huge an organization, it will be difficult to attain a level of experience matching that readily available for a product that is commonly made use of in numerous business. Thus, increasingly, universal frameworks such as Struts and Hibernate have pertained to replace in-house structures in specific areas.
The Need of Spring
Using J2EE “from the box” is not an appealing option. Lot of J2EE APIs and services are difficult to use. J2EE does a great job of standardizing low-level infrastructure, addressing such troubles as how can Java code access purchase management without taking care of the specifics of XA transactions. Yet J2EE does not provide a quickly useful view for application code. That is the role of an application framework, such as Spring. Spring allows you to appreciate the vital advantages of J2EE, while minimizing the intricacy run into by application code. The essence of Spring is in providing enterprise solutions to Level Old Java Objects (POJOs). This is particularly valuable in a J2EE environment, but application code provided as POJOs is naturally recyclable in a variety of runtime atmospheres.
The Spring Framework outgrew using J2EE without frameworks, or with a mix of internally frameworks. However, unlike Struts, Hibernate, and most other frameworks, Spring provides services for use throughout an application, not merely in a single architectural tier. Spring aims to eliminate much of the pain resulting from the issues in the list we have actually viewed, by simplifying the programming model, as opposed to hiding complexity behind a complex layer of devices. In agile J2EE, Spring framework is the most effective platform.
Technologies
While Spring Framework has provided innovation, many of the ideas it has popularized were part of the zeitgeist and would have become important even had there been no Spring project. Spring’s greatest contribution– besides a solid, high quality, implementation– has actually been its mix of arising ideas into a coherent whole, along with an overall architectural vision to help with effective use.
Inversion of Control and Dependency Injection
The modern technology that Spring Framework is widely known is Inversion of Control (or IoC), and especially the Dependency Injection of IoC. Spring is commonly taken an Inversion of Control container, although in reality it is much more.
Inversion of Control is very well understood through the term the “Hollywood Concept,” which basically indicates “Don’t call me, I’ll call you.” Consider a conventional class collection: Application code accountables for the overall flow of control, shouting to the class library as needed. With the Hollywood Concept, framework code conjures up application code, working with overall workflow, instead of application code summoning framework code.
IoC is a wide concept, and could encompass several things, consisting of the EJB and Servlet model, and the portal which Spring makes use of callback interfaces to allow clean acquisition and release of resources such as JDBC Connections.
Summary
As you could have already understood, we actually think that most applications must use a light in weight Dependency Injection container. Inversion of Control promotes loose coupling and testability of your code, the POJO programming model is how it should have always been. (IoC really enables testabillity of the code, the POJO programming model, etc). Spring is the most preferred and extensively approved DI container there is for Java. It’s entirely up to you just how much you use it. You can prefer to merely use some of the supporting classes or templates, or you can go full out and make your entire application use Spring grains. Besides the core Spring functionality which we covered here, over the years a bunch of extra components showed up which do replace already existing technologies. For example Spring Web Flow is a very nice framework developed upon the Spring framework for constructing Web applications.
With Spring Framework, it’s your choice which API’s you use, and how you develop your application.
