Discussions

Web tier: servlets, JSP, Web frameworks: JSF - Backing Beans and DTOs

  1. JSF - Backing Beans and DTOs (6 messages)

    Hi!

    Does anyone know about a "best practice" or Design Pattern for the relationship of a JSF Backing Bean and a DTO (Data Transfer Object)?
    Often the backing bean holds data to be displayed as well as controller functionality.
    In a J2EE environment the data is transferred to the presentation tier via DTOs (Data Transfer Objects).
    Now, it is likely that the data presented to the user is the data from the DTO.
    I wonder what is the best way to access the data stored in the DTO.

    I see two ways:

    1.) Duplicate every property from the DTO to the backing bean and copy the properties via apache common-beanutils.
    The disadvantage is that I have to deploy every new property/attribute twice: In the DTO and in the backing bean.
    (I read about this approach on http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf.html

    2.) Keep a reference to the DTO in the backing bean.

    public class PersonBean{
      private PersonDTO dto;
      
      In the JSP:
        ...value="#{personBean.dto.age}"

    This solution couples the backing bean to the dto what maybe is not desired.

    Does anyone have a good solution?

    Cheers,
    Jan

    Threaded Messages (6)

  2. JSF - Backing Beans and DTOs[ Go to top ]

    Hi!Does anyone know about a "best practice" or Design Pattern for the relationship of a JSF Backing Bean and a DTO (Data Transfer Object)?Often the backing bean holds data to be displayed as well as controller functionality.In a J2EE environment the data is transferred to the presentation tier via DTOs (Data Transfer Objects).Now, it is likely that the data presented to the user is the data from the DTO.I wonder what is the best way to access the data stored in the DTO.I see two ways:1.) Duplicate every property from the DTO to the backing bean and copy the properties via apache common-beanutils.The disadvantage is that I have to deploy every new property/attribute twice: In the DTO and in the backing bean.(I read about this approach on http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf.html2.) Keep a reference to the DTO in the backing bean.public class PersonBean{  private PersonDTO dto;    In the JSP:    ...value="#{personBean.dto.age}"This solution couples the backing bean to the dto what maybe is not desired.Does anyone have a good solution?Cheers,Jan

    Hi, I had the same interrogation. The best approach would be to store your domain objet directly in your backing bean.
    Otherwise, no need to seperate anything, you would just add complexity to your to your backing beans. A change in the DTO, adding a new property for instance, would have to be also done in the backing bean.

    BTW, do you really need DTO objects? Is your business logic layer deployed on a different layer then your presentation layer? If it is the case and you use a R/O persistance framework like Hibernate, don't bother with DTO and expose your domain objects directly in your backing beans.

    DTO had 2 purposes but most people agree they are an anti-pattern now :
    1) Transferring data between two nodes. Web <-> EJB for instance.
    2) Avoiding to pull out too much data if the table read by the service called is connected to many other tables, so you end up reading several tables when you don't need necessarily all this datas. Usually you solve this problem by supporting a detailled DTO and a simple DTO based upon
    the same table. Hibernate eliminate this problem by allowing lazy loading of data.
  3. Hi!Does anyone know about a "best practice" or Design Pattern for the relationship of a JSF Backing Bean and a DTO (Data Transfer Object)?Often the backing bean holds data to be displayed as well as controller functionality.In a J2EE environment the data is transferred to the presentation tier via DTOs (Data Transfer Objects).Now, it is likely that the data presented to the user is the data from the DTO.I wonder what is the best way to access the data stored in the DTO.I see two ways:1.) Duplicate every property from the DTO to the backing bean and copy the properties via apache common-beanutils.The disadvantage is that I have to deploy every new property/attribute twice: In the DTO and in the backing bean.(I read about this approach on http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf.html2.) Keep a reference to the DTO in the backing bean.public class PersonBean{&amp;nbsp;&amp;nbsp;private PersonDTO dto;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;In the JSP:&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;...value="#{personBean.dto.age}"This solution couples the backing bean to the dto what maybe is not desired.Does anyone have a good solution?Cheers,Jan
    Hi, I had the same interrogation. The best approach would be to store your domain objet directly in your backing bean.Otherwise, no need to seperate anything, you would just add complexity to your to your backing beans. A change in the DTO, adding a new property for instance, would have to be also done in the backing bean.BTW, do you really need DTO objects? Is your business logic layer deployed on a different layer then your presentation layer? If it is the case and you use a R/O persistance framework like Hibernate, don't bother with DTO and expose your domain objects directly in your backing beans.
    If it is *not* the case...
  4. Hi!Does anyone know about a "best practice" or Design Pattern for the relationship of a JSF Backing Bean and a DTO (Data Transfer Object)?Often the backing bean holds data to be displayed as well as controller functionality.In a J2EE environment the data is transferred to the presentation tier via DTOs (Data Transfer Objects).Now, it is likely that the data presented to the user is the data from the DTO.I wonder what is the best way to access the data stored in the DTO.I see two ways:1.) Duplicate every property from the DTO to the backing bean and copy the properties via apache common-beanutils.The disadvantage is that I have to deploy every new property/attribute twice: In the DTO and in the backing bean.(I read about this approach on http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf.html2.) Keep a reference to the DTO in the backing bean.public class PersonBean{&amp;amp;nbsp;&amp;amp;nbsp;private PersonDTO dto;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;In the JSP:&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;...value="#{personBean.dto.age}"This solution couples the backing bean to the dto what maybe is not desired.Does anyone have a good solution?Cheers,Jan
    Hi, I had the same interrogation. The best approach would be to store your domain objet directly in your backing bean.Otherwise, no need to seperate anything, you would just add complexity to your to your backing beans. A change in the DTO, adding a new property for instance, would have to be also done in the backing bean.BTW, do you really need DTO objects? Is your business logic layer deployed on a different layer then your presentation layer? If it is the case and you use a R/O persistance framework like Hibernate, don't bother with DTO and expose your domain objects directly in your backing beans.
    If it is *not* the case...

    BTW, your domains objects would have to be serializable if you want to not use DTO.
  5. JSF - Backing Beans and DTOs[ Go to top ]

    Hi,
    thanks for your answers.
    Unfortunately right now we'll have to stick to EJB 2.x (grrmph!), so there will be the need for using DTOs.
    Then maybe it is good to use, let's say, a PersonHandler as backing bean that does not directly keeps the data (age, int, ...) but holds a reference to the DTO to retrieve the data. This handler could then provide the controller functionality (or delegate it), and we were still able to generate the DTOs via XDoclet.
    So a new property is only stored in the DTO and not in the backing bean directly.

    Jan
  6. JSF - Backing Beans and DTOs[ Go to top ]

    Hi,thanks for your answers.Unfortunately right now we'll have to stick to EJB 2.x (grrmph!), so there will be the need for using DTOs.Then maybe it is good to use, let's say, a PersonHandler as backing bean that does not directly keeps the data (age, int, ...) but holds a reference to the DTO to retrieve the data. This handler could then provide the controller functionality (or delegate it), and we were still able to generate the DTOs via XDoclet.So a new property is only stored in the DTO and not in the backing bean directly.Jan

    Yeah this is the way to go, by the way the backing bean is part of the model of the MVC trinity :) The model is also made of the UI components. The model can usually be splitted in two : visual model (UI component), data model (backing beans and usually DTO).

    The input controller (the C in MVC) would be the faces servlet and the event dispatcher. It is already implemented for you.

    Finally, the view is made of the different UI components renderers and jsp tags.

    The application controller wich is a very different beast from the controller in MVC and has nothing to do with it is the ViewHandler. The application controller is responsible to handle the application navigation and read the current url value to know wich input controller has to be called.

    I can't count how many times I have seen bad explanations of MVC. MVC has nothing to do with layers like most explanations say. Sorry for this long post (especially if you already know this) but I always try to clarify the MVC whenever I can because there are so many mistakes on the web and even in the book.
  7. JSF - Backing Beans and DTOs[ Go to top ]

    MVC has nothing to do with layers like most explanations say. Sorry for this long post (especially if you already know this) but I always try to clarify the MVC whenever I can because there are so many mistakes on the web and even in the book.

    No need to be sorry :)
    Thanks for the helpful explanation. I find it always useful to read (correct explanations :) about the MVC pattern because I'm not too experienced with it.

    Jan