Sewing Up the Seam
One of my favorite things about Seam is that it fills in the holes that Java EE 5 leaves open. Much of the code developers typically write to manage APIs and frameworks is managed by Seam, leaving time to focus on bigger picture issues. It does this without forcing you into a specific type of architecture.
While API management is a big win, Seam's contextual management of state makes coding feel and look closer to the requirements. I found it much easier to concentrate on functionality rather than how the application server implements a Java specification. I'm not bogged down with EJB complexity as an added blessing.
There are, however, a few things that I don’t like about my SEAM application. The generated code could have a better separation of concerns. For example, the Editor and Finder do what you would expect them to do but most of their methods return strings. Those strings are used by the page flow model to determine the next page to display. Its not only doing editing and finding, it's also doing page flow and paging.
The selectors not only help you select an object from a list, but they also determine the labels on buttons and page titles. The worst part for me was finding that the LocationSelectors make calls back to the ReservationEditor. I feel this violates basic OO principles of proper object relationships. I would prefer code that deals with the back end, such as building SQL to do searches and lists in the finders and maintain a separation from the code that determines which page to go to next. The selector object is doing three different things; the code to do those things should be in three different objects.
Finally, the generated code uses the div tag to do layout and therefore did not look good in IE but did look good in Mozilla Firefox. Most importantly, keep in mind that Seam is beta.
Those issues aside, Seam can reduce the amount of code you need for your integration work, your business logic, and your front end. In the Customer object of my application alone I saw a difference of 800 lines. In a large system with hundreds of key domain objects and millions of lines of business logic, I estimate you can expect a 40 to 60 percent reduction in code lines. And considering that the more lines of code you have the more expensive your application is to maintain, Seam should by all accounts deliver ROI quickly.