Choose many Spring contexts over a single context
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.
- applicationContext.xml
- applicationContext-dao.xml
- applicationContext-dao-datasource.xml
- applicationContext-ldap.xml
- applicationContext-aspects.xml
- applicationContext-web.xml
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?
Related Posts
Comments
2 Responses to “Choose many Spring contexts over a single context”
Leave a Reply
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
@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.