IBM has posted a flamebait article detailing “best practices for J2EE application development”. Lists such as this can be helpful, but they’ve forgotten the simple complexity of the number of layers and complexity matching the complexity of the app. Many of the practices are good starting points, but by no means should they be rules.

The best practices

   1. Always use MVC.
   2. Apply automated unit tests and test harnesses at every layer.
   3. Develop to the specifications, not the application server.
   4. Plan for using J2EE security from Day One.
   5. Build what you know.
   6. Always use Session Facades whenever you use EJB components.
   7. Use stateless session beans instead of stateful session beans.
   8. Use container-managed transactions.
   9. Prefer JSPs as your first choice of presentation technology.
  10. When using HttpSessions, store only as much state as you need
      for the current business transaction and no more.
  11. In WebSphere, turn on dynamic caching and use the WebSphere servlet
      caching mechanism.
  12. Prefer CMP Entity beans as a first-pass solution for O/R mapping
      due to the programmer productivity benefits.

1. Always? What if I’m writing a one page app? What if all I want is a page that displays the time? There are such things as apps too simple for MVC.

2. Units tests at every layer? I’ve challenged for some time the degree to which some people suggest that you test your data access layer. Suppose you want to test a simple DAO class that retrieves an object by its id from a database using Hibernate. If that method simply calls Session.load(Class c, Object id), what are you really testing there? Hibernate? Your configuration? What database do you test against, and which values do you compare to determine success? The value/effort ratio is pretty low here.

3. The point is not to get into app server specific configuration and coding. The problem is that they use the example of J2EE security. What’s the issue? Well, in order to use J2EE security, you have to configure JAAS in a way that is app server proprietary. A good general principle, but it can’t be strictly followed.

4. A topic near and dear to my heart, security. Turn it on always? What if your app doesn’t need security? What if you need 2 factor authentication, which isn’t supported by J2EE security? Favor the use of J2EE security, yes. Always turn it on? No way.

5. Build what you know – an okay philosophy, I suppose. Basically, build your app a layer at a time instead of building it all at once. I’d say to at least fire a tracer bullet first.

6. ALWAYS use session facades with EJB components? Even if your app only has two stateless session beans? Overengineered. Refactor the session facade in later when complexity justifies it.

7. Avoid stateful session beans when possible. Fair enough – they’ve given some wiggle room here, which makes it reasonable.

8. Use container managed transactions. Fine.

9. Prefer JSPs. I actually generally agree with this. This step actually suggests that developers fight the urge to get fancy with XML/XSL when the requirements don’t justify it. Tapestry users get a pass here – though I personally find Tapestry to be a bit cumbersome, it can’t be equated with the whole XSLT to generate HTML crowd.

10. Use the HttpSession only for what you immediately need for this business transaction. The goal is noble – keep the session small so you can persist sessions and improve performance. Saying to only put info for the current transaction is a bit limiting. It seems plausible to also store general into about the application, or data about another transaction recently completed. Keeping the session small should be the actual suggestion.

11. In websphere… … turn on caching. Maybe – don’t know enough about their caching implementation to comment.

12. Prefer CMP Entity Beans for the productivity benefits. Although EJB 2.0 has made great strides, the Entity Bean model is already so cumbersome and has some limitations that make it a questionable choice at best. This is typical vendor-speak.