2 Replies Latest reply on Feb 11, 2008 3:12 PM by norman.richards

    Seam & Services management

    charliem

      Hi,

      What are the strategy/patterns proposed by Jboss Seam to link Seam framework with a service layer ?

      Most of the frameworks like Struts, Seam, ... propose solutions to facilitate the work of the web designer, web developer but they don't present anything concerning the strategy to adopt in order to integrate the actions with service layer. The action is not at all the right place where to put the business logic. For the Struts world, appfuse has been an interesting example where such a strategy was presented but for Seam ...

      Remarks :
      - What I mean by service layer are java classes where the business logic is defined. These java classes will contain methods like "calculateFee", "changeOrderStatus".
      - Maybe, this is a chapter that should be added in the future in the Seam documentation
      - Most of the examples presented in the JBOSS-SEAM-2.0.0.GA took the assumption that the data will be updated from POJO but I'm not sure at all that such approach is tolerated in enterprise world where DAO pattern must be used

      Regards,

      Charles

        • 1. Re: Seam & Services management
          mail.micke

          Hi

          Seam and JSF doesn't force any kind of design pattern on you.

          JSF in general is built with dependency injection as a cornerstone and Seam uses and enhances this functionality.

          So you can define your service anyway you like and inject the into the backing beans( which are called from the web interface), the backing beans would then delegate to your services.

          Cheers

          • 2. Re: Seam & Services management

            Make them Seam components and use them as you wish. In general, I think you'll find that you can define your entire application in terms of those "service layer" things and write very little in terms of glue code. (the "action" layer, as you describe it) Where you can't, you simply layer your application. There's absolutely nothing tricky about any of this.

            As to the DAO issue, I think you'll find in Seam that if you are doing anything tricky you'll want to use some sort of controller object to manage your entities. That's what the EntityHome and EntityQuery objects do in Seam. If you are forced to over-architect your application, you'll probably end up either modifying your DAOs to actually perform some useful functions in the context of Seam or creating a controller of some sort that delegates off to your DAO.