3.2. Lightweight Design
Hibernate, mainly driven by Gavin King, was one of the first successful reactions to the over complex EJB 2 specification, closely followed by the Spring Framework by Rod Johnson & co.
Hibernate introduced a simplified open-sourced Object Relational Mapping (ORM) API which blew away the complex EJB2 API. Not only does Hibernate work outside of a Java EE container allowing us to write tests in a straight forward manner, it also introduced a simple object relation mapping language. Almost overnight many enterprise Java developers were replacing DAO entity beans with Hibernate.
With the introduction of the Spring framework many enterprise Java developers had finally a simple POJO alternative for EJB2. The "J2EE without EJB" book by Rod Johnson had an enormous impact on the enterprise Java development where test-driven development and pure object oriented programming concepts like inheritance and polymorphism were again available in the enterprise Java development scene. In addition concepts like Inversion Of Control (Ioc) and Aspect Oriented Programming (AOP) became more main-stream through this new and exciting framework called Spring.
Both Hibernate and the Spring framework had an enormous impact on the ease of development theme of Java EE 5, resulting with the introduction of Java Persistence API (JPA = Hibernate), EJB3 development based on POJO's, annotations (the XDoclet impact), dependency injection (= simplified version of Spring IoC) and EJB3 interceptors (= AOP for dummies). Java EE 5 is out of scope for this section.
Figure 1
For the lightweight enterprise Java design we'll focus on the Struts framework for the presentation layer, Spring-enabled POJO's for the service/business layer and Hibernate for the persistence layer. If we exclude JEE5 then the mentioned APIs are the main stream solutions for todays enterprise Java development projects. The Ruby-on-Rails look-a-likes for the presentation layer are out of scope for this chapter 
Before we dive into the different layers we'll need to explore some lightweight concepts which are available in all the layers of the enterprise application.
Dependency Injection - Inversion Of Control (IoC)
The Hollywood principal: Don't call us, we'll call you.
The basic idea is that if an object depends upon having an instance of some other object then the needed object is "injected" into the dependent object. For example the Customer service needs a related DAO then adding a setCustomerDAO(...) method will signal the container to get an instance of CustomerDAO and inject the reference by calling your setter method.
Wikipedia
The pattern seeks to establish a level of abstraction via a public interface, and to remove dependency on components by (for example) supplying a plug-in architecture. The architecture links the components rather than the components linking themselves or being linked together. Dependency injection is a pattern in which responsibility for object creation and object linking is removed from the objects themselves and transferred to a factory. Dependency injection therefore is inverting the control for object creation and linking, and can be seen to be a form of IoC.
There are three common forms of dependency injection: setter-, constructor- and interface-based injection.
Dependency injection is a way to achieve loose coupling. The technique results in highly testable objects, particularly when applying test-driven development using mock objects: Avoiding dependencies on the implementations of collaborating classes (by depending only on interfaces that those classes adhere to) makes it possible to produce controlled unit tests that focus on exercising the behavior of, and only of, the class under test. To achieve this, dependency injection is used to cause instances of the class under test to interact with mock collaborating objects, whereas, in production, dependency injection is used to set up associations with bona fide collaborating objects. |
Aspect Oriented Programming (AOP)
XML Configuration
