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

I'm currently trying to get into the Java EE development with the Spring framework. As I'm new to Spring, it is hard to imaging how a good running project should start off.

Do you have any *best practices*, tipps or major *DO NOTs* for a starter? How did you start with Spring - big project or small tutorial-like applications? Which technology did you use right away: AOP, complex Hibernate...

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!

I actually quite liked Spring.. It was a fresh breeze of air in your average J2EE Java Beans..

I recommend implementing the example Spring provides:

[To see links please register here]

Also, I decided to go full monty and added Hibernate to my Spring application ;), because Spring provides excellent support for Hibernate... :)

I do have a DON'T however, which I learned the hard way (product in production)... If you only implement the Controller interface, and return a ModelAndView object with some data as provided with the interface, Spring does garbadge collect those resources, for tries to cache those data. So be careful to put large data in those ModelAndView objects, because they will hog up your server memory for as long as the server is in the air as soon as that page has been viewed...

A good way to get started is to concentrate on the "Springframework". The Spring portfolio has grown to a big pile of projects around various aspects of Enterprise Software. Stick to the core at the beginning and try to grasp the concepts. [Download][1] the latest binaries and check out Spring's petclinic example once you are familiar with the core. It gives quite a good overview of the various projects SpringSource has to offer.

Although the documentation is very good, [I'd recommend a book][2] after you grasp the concepts of the core. What I've found problematic with the documentation, is that it's not in depth and can't give you all the details you need.


[1]:

[To see links please register here]

[2]:

[To see links please register here]

Spring is also very much about unit testing and therefore testability of your classes. That basically means thinking about modularization, separation of concerns, referencing a class through interfaces etc.

If you're just looking to dabble in it a bit and see if you like it, I recommend starting with the DAO layer, using Spring's JDBC and/or Hibernate support. This will expose you to a lot of the core concepts, but do so in a way that is easy to isolate from the rest of your app. This is the route I followed, and it was good warm-up before getting into building a full application with Spring.

Start here - I actually think it's among the best Software Dev books that I've read.
[Expert Spring MVC And Web Flow][1]

Learn the new Annotation-based configuration for MVC classes. This is part of Spring 2.5. Using Annotation-based classes is going to make writing Unit tests a heck of a lot easier. Also being able to cut down on the amount of XML is a good thing.

Oh yeah Unit Tests - if you're using Spring, you BETTER be Unit Testing. :) Write Unit tests for all of your Web and Service Layer classes.

Read up on Domain Driven Design. The fact that you can use Domain Object classes at all levels of a Spring Application means you're going to have a VERY powerful Domain Model. Leverage it.

However, when using your Domain Object classes for form population, you will want to take heed of the recent security concerns around the Spring Framework. [A discussion on the Server Side][2] reveals the way to close the hole in the comments.


[1]:

[To see links please register here]

[2]:

[To see links please register here]

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][1]. I've used this before to give new team members a high-level overview of our application's organization.

[1]:

[To see links please register here]

"...Which technology did you use right away: AOP, complex Hibernate..." - I'd say a better question would be to ask what people did not use right away. I'd add the examples you cite to that list.

Spring MVC and JDBC template would be my starting recommendations. You can go a very long way just with those.

My recommendation would be to follow the Spring architectural recommendations faithfully. Use their layering ideas. Make sure that your web layer is completely detachable from the rest. You do this by letting the web tier interact with the back end only through the service layer.

If you want to reuse that service layer, a good recommendation is to expose it using Spring "contract first" web services. If you start with the XML messages that you pass back and forth, your client and server can be completely decoupled.

The IDE with the best Spring support is IntelliJ. It's worth spending a few bucks.

With the release of Spring 2.5 and 3.0, I think one of the most important best practices to take advantage of now are the Spring annotations. Annotations for Controllers, Services, and Repositories can save you a ton of time, allow you to focus on the business logic of your app, and can potentially all you to make all of your object plain old Java objects (POJOs).