10 Replies Latest reply on Dec 29, 2009 11:37 PM by Nirav Assar

    Weld design and best practices

    Arbi Sookazian Master

      related to this post: http://seamframework.org/Community/DeisgnAddingServiceAndDAOLayers


      what is the general recommendation for a large Weld app in terms of layering?

        • 1. Re: Weld design and best practices
          Pete Muir Master

          The same as Seam. I suggest picking up a good Seam book, it will explain it better than I can in a few sentences :-)

          • 2. Re: Weld design and best practices
            Arbi Sookazian Master
            I own at least 5 Seam books and have read most of them from cover to cover.  They generally do not cover design patterns in terms of layering (although JPwH does in terms of DAO pattern but that's a ORM book) other than typically stating that Seam projects do not require layering (JSF --> backing bean --> entity class).  The design patterns that are covered are typically Seam-specific, like factory and manager component patterns. 

            As an interesting side note, I have not yet heard it mentioned in a Seam context (forum/book), that it's recommended to code using interfaces and implement the interface with a class using the strategy pattern like in Spring for polymorphism (substitute another implementation without affecting the client to the interface).
            • 3. Re: Weld design and best practices
              Nicklas Karlsson Master

              Arbi Sookazian wrote on Oct 31, 2009 17:26:

              As an interesting side note, I have not yet heard it mentioned in a Seam context (forum/book), that it's recommended to code using interfaces and implement the interface with a class using the strategy pattern like in Spring for polymorphism (substitute another implementation without affecting the client to the interface).


              Seam is so no-intrusive that design patterns don't need to be mentioned. The choise of framework shouldn't influence your design. If you have multiple implementations of a single function - sure you should program against an interface. If you have to program against an interface even if you know there will only be one implementation then something smells fishy. You should do the minimal thing that works, interfaces can be refactored out as needed...


              Just my two euro-cents...

              • 4. Re: Weld design and best practices
                Steven Boscarine Apprentice

                Arbi Sookazian wrote on Oct 31, 2009 17:26:

                that it's recommended to code using interfaces and implement the interface with a class using the strategy pattern like in Spring for polymorphism (substitute another implementation without affecting the client to the interface).


                Hi Arbi,


                I don't think Spring actually advocates that you use an interface unless it makes sense to do so.  Most of their examples do not use interfaces unless appropriate. I don't actually remember the Spring folks explicitly advocating that every bean use an interface. 


                I remember a lot of early documentation showing interfaces, but their latest documentation, more beans seem to not implement an interface than do.


                My guess is that the authors of those early examples thought you'd mock every component so you could write dogmatic unit tests in which your test only tests one component in pure isolation and mocks the entire stack beneath it. 


                As Nicklas said, you really don't want to use an interface unless you actually have 2 implementations.  All it does is make your code more annoying to navigate. 


                • 5. Re: Weld design and best practices
                  Arbi Sookazian Master

                  You all have some valid arguments...



                  Yes, the Strategy implementation is normally injected. My love of the Strategy pattern was one of the motivations for Spring :-) It becomes very simple.

                  --Rod Johnson
                  http://forum.springsource.org/showthread.php?t=18083


                  The Pro Spring Apress book I have recommends usage of the strategy pattern as well.  Maybe it's out-of-style in these JEE 6 days???


                  But being able to (and possibly pre-ready to) polymorphate your objects (plug in and out different implementations w/o breaking the client code) is pretty cool and that's the ability the strategy pattern gives you...


                  Yes, this does complicate your app but it does make it more flexible as well...

                  • 6. Re: Weld design and best practices
                    Gavin King Master

                    At one stage Spring certainly did advocate the use of interfaces for everything, but I'm sure their views have evolved over time.

                    • 7. Re: Weld design and best practices
                      Arbi Sookazian Master

                      Gavin King wrote on Nov 03, 2009 11:07:


                      At one stage Spring certainly did advocate the use of interfaces for everything, but I'm sure their views have evolved over time.


                      Perhaps, the advantage of using interfaces with strategy pattern in the DAO layer, for example, is that you can plug in and out (polymorph) different implementations like iBATIS, Hibernate, JPA, etc. w/o breaking the client.  Seems convenient.


                      I don't see how/when/why that will go out of style.  But I guess you could always retrofit the interface when/if you need it...


                      A good counter-example is you don't need/use the local interface with SFSB/SLSB implementation class in EJB 3.1, correct?  I always thought that the EJB container should have been able to create or infer the local interface based on the implementation class public methods and signatures...

                      • 8. Re: Weld design and best practices
                        Gavin King Master

                        Perhaps, the advantage of using interfaces with strategy pattern in the DAO layer, for example, is that you can plug in and out ("polymorph") different implementations like iBATIS, Hibernate, JPA, etc. w/o breaking the client. Seems convenient.

                        Yes, that is the claimed advantage, but I think it's a false sense of abstraction. I don't believe it is so easy to just abstract away the details of your persistence technology.



                        A good counter-example is you don't need/use the local interface with SFSB/SLSB implementation class in EJB 3.1, correct?

                        Right, that's one of the things I pressed hard for inclusion in EJB 3.1.

                        • 9. Re: Weld design and best practices
                          Arbi Sookazian Master

                          But now that we're using session beans everywhere - even for presentation logic - it's clear that defining the local interface for every bean is simply a PITA.

                          seems like a lot of those wishes made it into EJB 3.1.  But should we be using session beans everywhere - even for presentation logic?


                          hmmm...


                          isn't that possibly overkill if you don't need to do any CRUD operations in the JSF backing beans?


                          but I guess you get some container services like EJB3 timer, XA tx's, bean pooling, interceptors, etc. for free...  most of which (like interceptors and sub-optimal tx support) are available in Seam for POJOs...


                          and you can incrementally hot-deploy POJOs, not EJBs (currently).  if EJBs were hot-deployable by Seam, for example, that would be a major plus...

                          • 10. Re: Weld design and best practices
                            Nirav Assar Newbie

                            A simple your way to layer your app starting out is to have three layers. 


                            - UI


                            - Controller


                            - Domain


                            This follows a basic MVC pattern.  Seam's purpose is to collapse the many manufactured layers that J2EE (and the patterns that have followed it) typically contains. 


                            For example a previous project I worked on used J2EE EJB2.0 with JSF and hibernate. We had all necessary layers and used traditional J2EE patterns. This was layered as follows:


                            - UI (jsps)


                            - Backing beans (JSF)


                            - DTOs (pojo transfer objects)


                            - Session Beans (EJB)


                            - Domain (Pojo entity objects)


                            - DAO (persistence layer with Hibernate)


                            The current project i am on uses seam to simplify this.  Seam essentially binds together several of the layers where it is unnecessary.  Of course, where necessary you can always create a layer if needed for resuse or if you find a layer is brittle and is changing with unrelated requirement changes.