What's your "best practice" for the first Java EE Spring project? [closed]

Small tip - I've found it helpful to modularize and clearly label my Spring xml context files based on application concern. Here's an example for a web app I worked on:

• MyProject / src / main / resources / spring /
  • datasource.xml - My single data source bean.
  • persistence.xml - My DAOs/Repositories. Depends on datasource.xml beans.
  • services.xml - Service layer implementations. These are usually the beans to which I apply transactionality using AOP. Depends on persistence.xml beans.
  • controllers.xml - My Spring MVC controllers. Depends on services.xml beans.
  • views.xml - My view implementations.

This list is neither perfect nor exhaustive, but I hope it illustrates the point. Choose whatever naming strategy and granularity works best for you.

In my (limited) experience, I've seen this approach yeild the following benefits:

Clearer architecture

Clearly named context files gives those unfamiliar with your project structure a reasonable place to start looking for bean definitions. Can make detecting circular/unwanted dependencies a little easier.

Helps domain design

If you want to add a bean definition, but it doesn't fit well in any of your context files, perhaps there's a new concept or concern emerging? Examples:

• Suppose you want to make your Service layer transactional with AOP. Do you add those bean definitions to services.xml, or put them in their own transactionPolicy.xml? Talk it over with your team. Should your transaction policy be pluggable?
• Add Acegi/Spring Security beans to your controllers.xml file, or create a security.xml context file? Do you have different security requirements for different deployments/environments?

Integration testing

You can wire up a subset of your application for integration testing (ex: given the above files, to test the database you need to create only datasource.xml and persistence.xml beans).

Specifically, you can annotate an integration test class as such:

@ContextConfiguration(locations = { "/spring/datasource.xml" , "/spring/persistence.xml" })

Works well with Spring IDE's Beans Graph

Having lots of focused and well-named context files makes it easy to create custom BeansConfigSets to visualize the layers of your app using Spring IDE's Beans Graph. I've used this before to give new team members a high-level overview of our application's organization.

Focus first on the heart of Spring: Dependency Injection. Once you see all the ways that DI can be used, then start thinking about the more interesting pieces like AOP, Remoting, JDBC Templates etc. So my best bit of advice is let your use of Spring grow out from the core.

Best practice? If you're using the standard XML config, manage the size of individual files and comment them judiciously. You may think that you and others will perfectly understand your bean definitions, but in practice they're somewhat harder to come back to than plain old java code.

Good luck!

First of all Spring is about modularity and works best if one focuses on writing small components that do one thing and do it well.

If you follow best practices in general like:

• Defining an interface rather than abstract classes
• Making types immutable
• Keep dependencies as few as possible for a single class.
• Each class should do one thing and do it well. Big monolithic classes suck, they are hard to test and hard to use.

If your components are small and follow the dogmas above they should be easy to wire up and play with other stuff. The above points are naturally also true of the Spring framework itself.

PS

Dont listen to the points above, they are talking about how to do whatever. Its more important to learn how to think rather than how to do something. Humans can think, repeating something is not clever, thinking is.