2 Replies Latest reply on Oct 24, 2006 9:50 AM by Todd Main

    Seam  and the old school of thinking

    Hardy Ferentschik Novice

      Hi there,

      I am still in the process of learning Seam and started wondering about the following.
      Seam proposes class design along this lines:

      public class RegisterAction implements Register
       private User user;
       private String verify;
       public String register()
       // register the injected user
       public String getVerify()
       return verify;
       public void setVerify(String verify)
       this.verify = verify;

      My first question is regarding the register() method. In what I will call 'old school' thinking the API would be register(User user). Is the former method not obfuscating the code. By just reading eg the JavaDoc for this class you would not know what's getting registered. You actually have to explicitly look at the code to see that a user gets injected and used in the register() method. Is this still consistent with OO design? Is this just something Java programmers have to get used to thanks to DI and annotations? Maybe it's just me beeing stuck in old school thinking?

      Another of these old school pattern which I see violated in the proposed design is that the EJB layer forms some sort of generic business interface. Using these interfaces you can build different clients interacting with the EJB layer, eg Web Services or even Swing GUIs. In the RegisterAction example I cannot reuse the Register interface to eg generate wsdl files for a web service. I have to create a whole new set of interfaces and underlying implementations. For the same reason the getter/setter for the verify string troubles me . It seems wrong to put this string into a stateful session bean.

      Maybe I am having the wrong angle on this? Maybe one should leave the concept of EJBs defining the business interface behind and just consider the beans as the clue which binds the presentation layer to the persistence layer?

      If my requirements however ask for different clients (eg web client, web service) I would have to introduce an additional 'old school' EJB layer.

      What do other people think?


        • 1. Re: Seam  and the old school of thinking
          Gavin King Master

          You can use the register(user) approach if you like. Seam 1.1 lets you write "#{register.register(user)}" as a method binding expression. (Plain JSF does not.) It all depends upon whether you view the user as "contextual state" or just a transient argument to a method. In this case its just a matter of taste.

          If you have a need to expose the functionality as a web service, then by all means layer your application to separate "business logic" from "interaction logic". But most applications do not start out with this requirement, it is something that comes later. People think just because maybe they will need the layering at some unspecified future date, that they had better introduce it *now*. But of course, this is a classic case of YAGNI. The easiest thing on earth (assuming modern refactoring tools) is to introduce extra layering into an existing application. The idea that this was difficult originated prior to the existence of "extract method".

          • 2. Re: Seam  and the old school of thinking
            Todd Main Newbie

            I still feel evil when I pass persistent objects out to the UI, but I've been using Java from "the beginning", and I have yet to really benefit from Value Objects. On the other hand, I have spent lots of time maintaining them, and it's really refreshing to have such a lean application with Seam, JSF, and EJB3.

            The layers were supposed to isolate us from change so we could avoid collatoral damage, but instead they created a huge maintenance burden that spawned the need for code generation just to keep up. With these new technologies, the code generation is still there, but it's hidden from me by the frameworks and handled automagically. And frankly, when I changed a business component, I wanted to propagate that change out to the UI. The UI is the application - everything else is just the servent of the UI.

            I have to say I still get uncomfortable when I add a transient "selected" attribute to a business object to assist with the UI, but you know what? The UI logic is the business logic, so I put the attribute in the entity and move on.

            I'm so glad we have a new generation of thinkers involved in EJB, etc., to remind us that many of the former J2EE patterns were just workarounds to an awkward technology and a lack of good IDEs.