Discussions

EJB design: Value Object and DTO few questions

  1. Value Object and DTO few questions (6 messages)

    Hi,

    Can someone let me know what is the difference between a Value Object and Data Transfer Object? Or is there none?
    Does the difference lies in the fact that DTO are used between Business Layer and Data Layer whereas VO are used more between Presentation Layer and Business Layer? As far as I understand, both are coarse grained object meant to carry data.

    Also, what are some design choices to mark a field dirty, something I can do when I call set<attribute name>. I was thinking of using BitSet but that seems to entail lot of manual, fragile code (what if the order of attribute changes?) for developer creating the class.

    Can these object contain some a) basic business logic b) reference to other Value Objects? Or will that be bad design.

    Thanks in advance
  2. the difference between a Value Object and Data Transfer Object? Or is there none?

    It is my understanding that Data Transfer Object, Transfer Object, and Value Object are all synonymous terms for a simple JavaBean-compliant object used to transport information into and out of the model in an MVC architecture. Generally, these objects are also made serializable so that they can be transported across RMI if the application calls for it.
  3. Thanks. And is it a good design to put some business logic (like attribute validations etc) or should that be the responsibility of another class?

    TIA
  4. Thanks. And is it a good design to put some business logic (like attribute validations etc) or should that be the responsibility of another class?TIA

    This is not quite as easy to answer. The ultimate answer is, of course, whatever you decide to do. I think the most common approach is that business logic is usually placed in some other part of the application. There are a lot of different approaches for this, but a common approach in a J2EE environment is to a)embed business logic in EJB entity beans and expose the business data to the EJB client through a DTO or b)use EJB entity beans to provide data access/persistence and expose the data through DTOs to an EJB Session Bean Facade, which provides a layer of business rules and logic. In the latter, case, it is likely the session facade would continue to use the DTOs to expose data to the EJB client, but this is certainly not a requirement.

    However, another approach may be to create a domain model using POJOs which include business logic (and thus you may not even want additional transfer objects) and use a persistance mechanism such as hibernate or iBATIS (or any of a number of other possibilities) to keep the data in that object model synchronized with a relational database.

    It all depends on your requirements and, to some extent, personal opinion as to what approach you choose.
  5. Value Object and DTO few questions[ Go to top ]

    If you look at Sun's patterns (link below), you will see that a "transfer object" is a course grain object to solve network overhead. Basically the are for Enity beans but could be for any type of remoting. See Martin Fowlers book on Enterprise Architecture to see how to deal with these.

    Unfortunately, an anti-pattern has emerged called data transfer beans. People think they need to separate layers using DTOs (ie the UI and Domain layer). You don't. If you are using POJOs and putting your business logic in them, you don't need DTOs.


    http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
  6. Value Object and DTO few questions[ Go to top ]

    If you are using POJOs and putting your business logic in them, you don't need DTOs.

    Does this mean that I can have serializable POJO which will have:

    1) Attributes for the columns in table(s)
    2) Other attributes which are NOT mapped to any columns in table(s)
    3) Methods which contain business logic. Any validations requiring fields of other classes will be handled in another class.
    4) Use these POJOs all the way to the presentation tier (use it JSF pages as beans), business layer (facades which handle validations spanning multiple such POJOs)

    If there are no cons to this approach, I think it can greatly simplify my design and avoid cluttering it with multiple classes.

    Another advantage I see is that they keep my core business logic independent of EJBs. If need arises, they can always be wrapped around by EJBs.

    Pleas advise,

    Thanks
  7. Value Object and DTO few questions[ Go to top ]

    If you are using POJOs and putting your business logic in them, you don't need DTOs.
    Does this mean that I can have serializable POJO which will have:1) Attributes for the columns in table(s)2) Other attributes which are NOT mapped to any columns in table(s)3) Methods which contain business logic. Any validations requiring fields of other classes will be handled in another class.4) Use these POJOs all the way to the presentation tier (use it JSF pages as beans), business layer (facades which handle validations spanning multiple such POJOs)
    Yes. For number 3 and object should validate its own attributes (data) or know how to (meaning the actual business rules are externalized in a rules engine).
    If need arises, they can always be wrapped around by EJBs.
    Or "wrap" the EJB using AOP and/or IOC and/or ...