7 Replies Latest reply on May 5, 2008 2:40 AM by zahidmaqbool

    Layering: what is recommended practice?

    jamesl

      I'm used to layering my applications and using spring.


      I have a presentation tier (web/jsp/js) which talks to a Spring Controller to handle the View related logic.
      The Controller talks to a Service which carries out the Business logic. This logic may require persistence which is handled via a Repository/DAO object injected into the Service or the Controller, depending on the scenario.


      In the Seam examples I am looking at the logic appears to be in one layer only, the action, which I'm equating as similar to the Spring Controller.


      What is the recommended layering in Seam?


      Does this change if there are two or more actions that want similar business logic?


      Eventually I'd like to take the responses and my experience and write a piece on Seam from a Spring users perspective.

        • 1. Re: Layering: what is recommended practice?
          jamesl

          ??

          • 2. Re: Layering: what is recommended practice?
            shane.bryzak

            There isn't really a recommended layering practice, what you see in the examples makes sense in the context of those examples.  If it makes sense within the context of your application to separate business logic into its own layer, then by all means architect it that way.  In the seamBay example, AuctionAction is a conversation-scoped component containing the business logic for creating a new auction listing.  It is used by both the web-based user interface, and also by the AuctionService web service.  This is just one example of how business logic can be reused.

            • 3. Re: Layering: what is recommended practice?
              jamesl

              Thank you for the reply.


              I'll go and have a close look at that example.


              The word 'recommended' is probably one I should not have used.

              • 4. Re: Layering: what is recommended practice?
                andygibson.contact.andygibson.net

                Hey James,


                Shane is right, it really depends on the application context. Another important factor (I think) is whether code is going to be re-used later on, either from another point in the same application, or from another client elsewhere.


                These things can always be refactored out later but if you know about it ahead of time, it can impact design decisions earlier.


                The first major layering decision though is whether to mix business logic and view logic in the same session bean. A lot of times we'll see code to handle button clicks in the same bean as the code to perform actions on entities.
                If we want to perform the same actions from other places in the code or even other applications, we may want to separate that out which is fine.


                You can further demarcate the layers based on state and function. The 'backing bean' session beans can hold the view state and logic, but any general functional code can be placed into stateless beans which have state passed in to them.


                The obvious benefits are that we put the method in one place and always use it to perform that action so if we decide to change it, or always send an email to someone when that action is performed, we can just put it in that one method.


                This is probably obvious to many as it is just good OO principles, but Spring always seemed to to put as many layers in as possible because of the (overstated IMO) need to change any layer at any given point in time. We started with MVC, and then Spring threw in service layers, repositories, Daos and so on.


                Seam is a little different, especially since it is based around a stack that probably 80% of people are going to use anyway, hence no need to swap out layers. With Seam you can just put layers where they are logical, or it is prudent to do so.


                Cheers,


                Andy Gibson



                • 5. Re: Layering: what is recommended practice?
                  jamesl

                  Andy,


                  Thank you for such a detailed and well thought out response.
                  Would you mind if I cross-posted your response in
                  My Blog ?


                  Yesterday I purchased and downloaded Seam in Action and section 1.4 made things click in my mind, how Seam removes the need to layer as aggressivly as I had in the past because it mediates between the layers so unobtrusively.


                  My desire to layer was not a Spring thing, but a general architecture approach to achieve simple, clean and targetted objects. I think I can achieve this in Seam with less code and less work, which is fantastic.


                  Go Seam !!


                  Thank you again.


                  Rgs, James.



                  • 6. Re: Layering: what is recommended practice?
                    andygibson.contact.andygibson.net

                    Thank you for such a detailed and well thought out response. Would you mind if I cross-posted your response in My Blog ?

                    Sure no problem.


                    Yes, seam removes a lot of the problems with layering because Seam itself is really just the 'stuff' that interweaves the different technologies (JPA, EJB, Jbpm, state management), and pulls it all together without being monolithic.


                    Cheers,


                    Andy Gibson

                    • 7. Re: Layering: what is recommended practice?
                      zahidmaqbool

                      Andy I was thinking about the samething... Your response has just cleared up a lot of things for me.. thanks