Discussions

EJB design: DTO Methods

  1. DTO Methods (8 messages)

    Hi,

    I want to know if DTOs which are essentially POJOs, can (or is ok to) have methods in addition to getters and setters?

    Methods I am thinking about are resetDTO and compareDTO - which do not impose any behavior as such on DTOs.

    Thanks,

    P I

    Threaded Messages (8)

  2. DTO Methods[ Go to top ]

    As I understand them, DTOs quite certainly are simply POJOs. As such, there are really two questions here:
    • Can we?
    •     
    • Should we?
    The first question is easy - yes. There is no DTO interface or abstract class to implement/extend (save perhaps Serializable if you are going over RMI), so you can theoretically do whatever you want.

    The second is really more a question of best practices and preference. In my opinion, it is okay, so long as it does not involve any real business logic. So, in your case, a reset and a compare certainly seem to fit here, at least assuming I understand the spirit of what you mean to do in these methods.
  3. DTO Methods[ Go to top ]

    I agree that DTO must not contain any business logic.

    I think that it is better to use DTO's standard 'equals' method instead of 'compareDTO' (or implement Comparable inteface depending on what you want).

    The other thing is that I prefer to always create new DTOs instead of reusing them. In this case you don't need 'resetDTO' method. The reason is that DTO are simpler and easier to use.
  4. DTO Methods[ Go to top ]

    ...I prefer to always create new DTOs instead of reusing them. In this case you don't need 'resetDTO' method. The reason is that DTO are simpler and easier to use.

    I agree. There's no real reason to reuse a DTO, since they are, by definition, lightweight components. And definitely look into implementing Comparable (or writing a Comparator, if you prefer that approach)
  5. DTO Methods[ Go to top ]

    I think that it is better to use DTO's standard 'equals' method instead of 'compareDTO' (or implement Comparable inteface depending on what you want).

    I guess I will have to override 'equals' in order to examine each attribute for equality?

    - PI
  6. DTO Methods[ Go to top ]

    I guess I will have to override 'equals' in order to examine each attribute for equality?- PI

    If you wish to compare the two objects, yes, and also note that when overriding equals, you should override hashCode() as well.
  7. DTO Methods[ Go to top ]

    ...If you wish to compare the two objects...

    For equality, I mean. you'll need more than than (i.e. Comparable) if you wish to compare for a sorting relationship.
  8. DTO Methods[ Go to top ]

    Correct me if I'm wrong, but:

    If you intend to do comparison beyond Object.equals(Object obj) method, you must overload hashCode, or hashing will not work in the way that you expect. Rules on overloading hashCode can be found here.
  9. DTO Methods[ Go to top ]

    ...If you intend to do comparison beyond Object.equals(Object obj) method, you must overload hashCode, or hashing will not work in the way that you expect...

    A bit of ignorance on my part, here, but I believe that you are correct. However, I base my assertion on the simple fact that it is good practice to always override hashCode() if you override equals().

    Technically speaking, you can get away with not doing so, as java.lang.Object provides a hashCode() implementation. However, this is true only if you are certain you will not need to work with any code that uses the hashCode() method (esp. HashMaps, etc.). It is good practice, however, even in these cases to go ahead and write a hashCode implementation.

    And to create a working (read: functional, but not necessarily optimal) hashCode is fairly simple. A common approach I take on simple objects is to create a new Long, set its value to the sum of the hashCodes of all the class's fields (if there are primitive fields other than int, wrap them and take the hashCode of the wrapped object), and simply return the value of hashCode() for the Long.