Is a DTO just a relection of a FormBean?

Discussions

EJB design: Is a DTO just a relection of a FormBean?

  1. Is a DTO just a relection of a FormBean? (4 messages)

    Is a data trasfer object supposed to have the same signature as a Form Bean's except that the DTO can have native datatypes where the FormBean must use Strings and other dts the can be used by JSPs?

    So if you have a formBean called User
    public class UserBean....{
     String getUserName() {...}
     void setUserName(String name) {...}
     String getUserId() {...}
     void setUserId(String id) {...}
    }

    public class UserDTO implements Serializabe {
     String getUserName() {...}
     void setUserName(String name) {...}
     int getUserId() {...}
     void setUserId(int id) {...}
     
    }

    Notice the difference between the data types..of course I'd have a static class that would handle these types of conversions.

    Am I on the right track with this?
  2. If your FormBeans are carbon copies of you DTO, you may be better off using DynaActionForms:

         http://jakarta.apache.org/struts/userGuide/building_controller.html#dyna_action_form_classes

    Also, your form beans and DTO don't necessarily need to match exactly. You DTO should match your domain model (EJBs). You FormBean should match your UI forms. The two may not look exactly the same. For example, you may have one form gathering data for several EJBs, and a form that gathers only some of the data for a large EJB.

    For simplicity, though, it is best to get your UI, DTO, EJB and Table structure to match as closely as you can.
  3. I just notices that in your response on another thread, you were not happen with Struts DynaForm features, so I retract that part of the suggestion. :)

    The rest of what I said still stands.
  4. Also, your form beans and DTO don't necessarily need to match exactly. You DTO should match your domain model (EJBs). You FormBean should match your UI forms. The two may not look exactly the same. For example, you may have one form gathering data for several EJBs, and a form that gathers only some of the data for a large EJB.


    From what I read the domain model (a.k.a business model) are your nouns (I got this from reading the EJB Design Patterns PDF found on this site. From what I inferred in reading that document (as well as other readings) DTOs should contain all the data needed to populate the FormBeans (hence the UI forms). So, if a UI page consists of information that make up two or more objects (like a Person object, and Address Object, and an Company object) shouldn't the DTO encapsulate all three of these objects that way we're only calling the Business layer (EJBs, DAOs, etc) through the network once? Otherwise, we'd have to do a getAddress, getPerson, and getAddress (3 hits) to get back those objects.

    I wouldn't want to write a Domain object that contains all the attributes of Person, Address, Employment because I want to reuse Address object with other nouns that have an address, like a Business or Residential address.

    I was planning on creating Custom DTOs that encapsulates all three of the Domain Objects then extracting them out in the Action classes and mapping them to the formbean. Then I was just planning on passing the Domain Object themselves (serving as DTOs) where a page maps directly to my UI form. The reason why I wanted to do this was the cut down on the number of classes I had. No since in writing a class with the EXACT same signatures, I'd just make my Domain Objects Serializable.

    Is this a bad practice to do (not having all the DTOs map 1 to 1 and using Domain Objects acting as DTOs).
  5. I have a suggestion to your problem. Let's say you have two DTOs, Person and Address. Address could be something like:

    class Address implements Serializable{

      String Street;
      Integer number;
    .........
    }

    And Person should be something like:

    class Person implements Serializable{

      String name;
      String surname;
      Address address;
    ...........
    }

    I suppose you have read about Lazy Loading. In case you want to know all the data about a Person, when you load the data for the person you also load the data for the Address because you have the AddressID from the Person table so you can load the address data also(this can be a 1 to 1 relationship, or 1 to N if a Person can have multiple Addresses).
    If you do not need the Address and you need only the Person's data, you don't load the Address DTO.
    You could differentiate these two cases in your Session Bean by implementing two methods, let's say findPerson(-loads all the data-) and findPersonNoDetail(-does not load any related DTO, only the Person DTO).
    Using this approach you solve the problem with multiple calls through the network and everything can be done through one call and you don't need any other custom data objects.

    Hope this helps