Spring Patterns: Best Practices and Design Strategies Book Review

This is a book review of Pro Java™ EE Spring Patterns: Best Practices and Design Strategies Implementing Java EE Patterns with the Spring Framework

About the Book

Apress describes this book as

Pro Java™ EE Spring Patterns focuses on enterprise patterns, best practices, design strategies, and proven solutions using key Java EE technologies including JSP™, servlets, EJB™, and JMS APIs.

This Java EE patterns resource, catalog, and guide, with it’s patterns and numerous strategies, documents and promotes best practices for these technologies, implemented in a very pragmatic way using the Spring Framework and it’s counters.

The book was written by Dhrubojyoti Kayal. Dhrubojyoti works as a senior consultant with Capgemini Consulting. He has more than five years of experience developing and designing applications and products leveraging Enterprise Java technologies. His areas of interest include the Spring Framework, ORM, SOA, refactoring, prefactoring, and performance engineering.

In this book the author takes us through the process of refactoring a legacy system built without using patterns or the Spring Framework into a shiny new system leveraging Spring and design patterns. Throughout the book he takes us through this practical, real-word example.

Introduction to the MVC Pattern

The first chapter introduces you to the MVC pattern. I think that this book is for a well versed J2EE professional developer, who would probably be familiar with the pattern, so this chapter may have been overkill. However, the basis of this book is to refactor an antiquated web application to use Spring and the Spring MVC, so a clear and thorough understanding of the MVC pattern is necessary. Most readers of this book can probably skip this chapter. On the other hand it is written well enough that it would serve a good resource for any rookie developers that you might be working with who need to learn this pattern.

Patterns

Each chapter of this book takes you through the concepts of a common pattern, describes how the Spring Framework is used to implement that pattern, and then replaces the legacy insurance system code with new spring code. Once you get into the patterns, the book is divided into four major sections. These sections are

This division helps to keep the conversation between the author and the reader focused and also makes it easy to find later when you come back to reference this information.

The Best Part

My favorite part about this book is that it is a patterns book. I like to read books based on patterns more than any other type of book. Patterns books are naturally broken down into small, manageable chunks of information. When written, patterns are usually described using a common, easy to follow template and are small enough to read an entire pattern in one sitting, whether that sitting be while you are eating your lunch or a quick read before hitting the pillow. Because they are written this way, it is easy to read this book very quickly and easy to find what you are looking for when you come back later for specific information. Pattern-based books are great.

I also liked this book because it takes you through all the layers of a real-world system. As developers we all have to work with legacy code. If you don’t your very lucky. Because this is real world it is very easy to follow along with the author and the project and see the benefits of Spring and refactoring to patterns.

Needs Refactoring

It’s a good, well-written book, but there are some things that I think need to be changed.

First, as with any book with code examples, there is some odd code that should be rewritten or removed. For example, there is a business bean that has a DAO injected into it via a setter. However, this bean also contains a getter for that DAO. This is not common practice and, in my opinion, not recommended.

And second, all of the presentation patterns are in a single chapter, and all of the business and integration patterns are in their own chapters. I think each pattern should have had its own chapter. I just prefer the clearer boundaries between patterns and I think it would make finding these patterns later, when I come to reference the book, a little easier.

You Should Read this Book

You should read this book if you are a developer who uses Spring, and especially if you use Spring MVC. This is a great resource and a great way to learn about how Spring utilizes patterns internally to implement its services. Of course it also shows you how to use Spring to add patterns to your current code base. You should read this book if you use an MVC framework that is not Spring MVC and are considering Spring MVC for  your next project or are considering adapting Spring MVC to your current project. While this book deals with more than just the Spring MVC, the entire presentation tier section is based on it.

Or Not…

I do recommend this book to most developers, however you should not read Spring Patterns if you are not well versed with J2EE/JEE and the Spring framework. If you are looking to learn Spring, there are other books that might be more suitable.

Here are some last notes, straight from Apress, about this book:

Table of Contents

Finally, here is the table of contents:

  • Share/Bookmark
August 16, 2009 | Filed Under Books, java | 3 Comments 

Getting friendly with Spring, JUnit and EasyMock.

Here are some steps that can get you using Spring, JUnit and EasyMock all together in some Test Driven Development hotness.

Start by adding the following lines to the top of your unit test. Specifying Autowire by name ensures you get the injection you want and will stop those Spring errors that there are more than one of the same type of mock objects in your mock-applicationContext.xml. When you specify the Spring Junit runner you must provide one ore more context configurations with @ContextConfiguration.

MyClassUnitTest.java

...
@Configurable(autowire = Autowire.BY_NAME)
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"classpath:com/some/domain/someproject/resources/mock-applicationContext.xml"})
public class MyClassUnitTest {
...
     @Autowired private Collaborator mockCollaborator;

     @Before
     public void setup() throws Exception {
     ...
     }

     @After
     public void teardown() throws Exception {
     ...
     }

     @Test
     public void testMyClass() throws Exception {

          //Set your mock behavior here
          ....

          EasyMock.replay(mockCollaborator);

          MyClass myClass = new MyClass(mockCollaborator);
          myClass.run();
          EasyMock.verify(mockCollaborator);

          // Other JUnit assertions
          ...
     }
 }

Then add your mocks to your mock-applicationContext.xml (an applicationContext in your test resources just for providing your unit tests with spring injection dependencies):

mock-applicationContext.xml

...
<bean id="mockCollaborator" name="mockCollaborator" class="org.easymock.EasyMock" factory-method="createStrictMock">
     <constructor-arg value="com.some.domain.someproject.Collaborator"/>
</bean>

<bean id="mockOtherCollaborator" name="mockOtherCollaborator" class="org.easymock.EasyMock" factory-method="createStrictMock">
     <constructor-arg value="com.some.domain.someproject.OtherCollaborator"/>
</bean>
...

Ensure your maven pom has the following test-scoped dependency:

pom.xml

...
<dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-test</artifactId>
     <version>2.5.6</version>
     <scope>test</scope>
</dependency>
...

Then use your mocks as normal. Make sure you call EasyMock.reset(mock) in your @After teardown() method so that each of your mocks are reset for each test. You can also tell Spring to reset the context after a test if needed with @DirtiesContext.

For official documentation and tutorials check out these links.

Spring

http://www.springsource.org/documentation

JUnit

http://www.junit.org

EasyMock

http://easymock.org/Documentation.html

  • Share/Bookmark
August 1, 2009 | Filed Under java | Leave a Comment 

Load Multiple Contexts into Spring

I have  already argued that many application contexts are better than a single application context. But how do you load more than one context?

There are a couple of ways to do this.

web.xml contextConfigLocation

Your first option is to load them all into your Web application context via the ContextConfigLocation element. You’re already going to have your primary applicationContext here, assuming you’re writing a web application. All you need to do is put some white space between the declaration of the next context.

<context-param>
    <param-name>
        contextConfigLocation
    </param-name>
    <param-value>
        applicationContext1.xml
        applicationContext2.xml
    </param-value>
</context-param>

<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

The above uses carriage returns. Alternatively, yo could just put in a space.

<context-param>
    <param-name>
        contextConfigLocation
    </param-name>
    <param-value>
        applicationContext1.xml applicationContext2.xml
    </param-value>
</context-param>

<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

applicationContext.xm import resourcel

Your other option is to just add your primary applicationContext.xml to the web.xml and then use import statements in that primary context.

In applicationContext.xml you might have…

<!-- hibernate configuration and mappings -->
<import resource="applicationContext-hibernate.xml"/>

<!-- ldap -->
<import resource="applicationContext-ldap.xml"/>

<!-- aspects -->
<import resource="applicationContext-aspects.xml"/>

Which strategy should you use?

I always prefer to load up via web.xml This allows me to keep all contexts isolated from each other. With tests, we can load just the contexts that we need to run those tests. This makes development more modular too as components stay loosely coupled, so that in the future I can extract a package or vertical layer and move it to its own module.

If you are loading contexts into a non-web application, I would use the import resource.

Any benefits to going with the application context import method over the web.xml contextConfigLocation?

  • Share/Bookmark
July 26, 2009 | Filed Under java | 1 Comment 

Next Page →