Choose many Spring contexts over a single context

Written by MikeNereson

July 26th, 2009 at 9:29 am

Posted in java

Tagged with , ,

With 2 comments

This is a short introduction to splitting up your bean definitions from one single Spring application context, to many application contexts. That is, from one XML file to many XML files. The general idea is to have one single primary application context, usually titled applicationContext.xml, and then many other application contexts with are named what they contain.

Example

For example, a single web project might contain the following contexts.

Breakdown

In this example, your DAO definitions, transaction managers, and DAO or integration interceptors are defined in applicationContext-dao.xml. We have further broken the DAO application context to a dao-datasource which contains our data sources. LDAP configuration, beans, and DAOs are in their own applicationContext-ldap.xml.

Benefits

Why so many? There have been a few benefits so far.

Responsibility

The Single Responsibility Principal is widely accepted and states that

… every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility.states that every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility.

The same holds true for XML contexts.  The general ides is to make our contexts more robust and to be able to isolate a context’s tasks and capabilities. And clearly, working with a smaller XML file is easier than working with one enormous file. It is easier to maintain and easier to read.

Testing

When I wrote my tests for LDAP, I had my LDAP configuration in applicationContext.xml, but then every time I ran an LDAP test, I would get the WebApplicationContext, which would import applicationContext-hibernate, which would connect to the database. Tests took forever and needless resources were used. Now I just get applicationContext-ldap.xml which only contains LDAP configurations, so no needless resources are loaded and tests remain quick.

Inclusion and Exclusion

Finally, its really easy to comment out a line like

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

and quickly have all my aspects, which for me only write logs, disabled. Or easy to add a line like

<import resource="applicationContext-dao-mock.xml"/>

which overrides all of your DAO implementations with mock DAOs. This would be for testing.

Does anyone else use multiple application context files? See any other benefits? Or problems?

  • Share/Bookmark

Related Posts

Comments

2 Responses to “Choose many Spring contexts over a single context”

  1. LeeC on March 19th, 2010 1:50 pm

    Thank you for the article. Technical details I can find on the net but best practices that comunicate the whys are harder to find.
    lee

  2. MikeNereson on March 19th, 2010 1:55 pm

    @LeeC – Thanks for your comments. And thats a good point. I haven’t ever heard that put that way before.

    I guess if someone asked me how to find best practices when it comes to a particular technology I would say go find an IRC channel for that technology and ask there. Although Spring does a pretty good job at describing the best practice when they write their documentation.

    Cheers.

Leave a Reply