dynadto
Project home

DynaDTO is a 100% pure Java library that simplifies applications implementing the Data Transfer Object pattern (also known as the Value Object pattern).

Latest News

• November 3, 2005: Spring Integration Available. Version 1.0 re-release (no version inc)
• August 23, 2005: DynaDTO initial release. Version 1.0. Includes JBoss integration
• June 27, 2005: DynaDTO initial beta release. Version 0.0.1

Project Information

• Project Name: DynaDTO
• Latest Release: 1.0
• Latest Release Status: Production
• Project Type:J2EE Utility
• Java Version:J2SE 5.0

DynaDTO is a project that provides a library that enables you to dynamically generate Data Transfer Objects that implement a given Java interface. DynaDTO was created by Brian Sam-Bodden, Floyd Carver and Joseph Nusairat to ease the burden of hand coding DTOs. DynaDTO eases the enforcement of separation of concerns between your application domain model and the user interface, reduces the amount of code required to implement the pattern and provide a consistent way to declaratively define simple and complex mappings between your domain model and your user interface model.

Special thanks to all the sponsors of this project.

Context

Data Transfer Objects are (typically) lightweight objects that are used for inter-tier communications. Generally, in object-oriented, distributed and middleware-driven web applications there are three well-known tiers connected by what we define as two transformation layers. The three tiers are usually known as the integration tier (and/or the data tier), the business tier (where the business/domain objects reside) and the presentation tier (for web application this is the web tier). Between these three tiers we typically encounter 2 transformation layers:

Problem

• Coarse-Grained Entities: Coarse grained technologies like Entity EJBs are not meant to be manipulated directly by the web tier, since every access can potentially become a remote call. Depending on temporal topology of an application (like collocation or vendor-specific optimizations) it can lead to portability problems and a brittle architecture.
• Fine-Grained Entities: A well-designed domain model reflects more about the problem domain that it is normally exposed to a client. A domain model (should) represent a subset of the knowledge about the problem/solution domain. Martin Fowler coined the term Anemic Domain Model to refer to the anti-pattern where a domain model lacks behavior. We see a lot "tainted" domain models, tainted either by the data tier or by the presentation tier. Separation of concerns is usually disregarded in order to accelerate development. In other words the user interface should deal with objects that are designed for the user interface to handle. You should not compromise the integrity of a domain model to satisfy the needs of the User Interface.
• Bulk-transfers: Distribution brings a plethora of problems, including the need to minimize network traffic by using bulk transfers of data. Other typical issues affected by the granularity of the data exchanged between tiers include pagination schemes and caching.

Forces

• Potential remote calls when accessing a field of a remote object using coarse grained technologies like Entity EJBs.
• Web applications are typically read-mostly and save-update-occasionally.
• Viewing requirements per page are typically composed of multiple attributes from multiple domain objects. Transferring all domain object needed to satisfy these requirements can result in a large object graph being serialized across tiers.
• Hand coded DTO mean that code needs to be develop to instantiate a DTO at runtime and populate its values from one or more sources.

Solution

Developers typically end up creating objects that are lightweight counterparts to the domain entities. The create Transfer Objects to encapsulate business data. For most Use Cases these translate to one DTO per use case that encapsulates the needs of the user interface.

Problems with the prevalent solution

• Parallel-Object Hierarchy: As pointed out by Gavin King of the Hibernate project a parallel class hierarchy to maintain is 'smelly'. We see this as a sign that the domain has been flattened by the influence of either the web tier requirements or the underlying data model. Although there will be obvious similarities between the domain objects and the DTOs we believe that a well-designed domain model will be fairly dissimilar to the DTO model in both structure and content. Remember, the domain model should be reusable between different applications dealing with the same problem domain.
• Code Maintenance: We find that maintaining these transformation and transport objects can add quite a bit of overhead to a project. We find this problem similar to the problem of maintaining a custom object-relational mapping layer.

Proposed Solution

After dealing with the above mentioned problems while developing many J2EE-based web applications we (Brian Sam-Bodden, Floyd Carver, Joseph Nusairat) created DynaDTO which is a solution to the screen-domain mapping problem similar to what Hibernate is to the object-relational mapping problem. DynaDTO is configured via an XML file that configures the DTO factory for a given DTO.

DTO can be constructed from one or more domain objects (actually any JavaBean or POJO). A DynaDTO configuration file (DTOs can also be configured inline using Java) uses simple property mappings, nested properties and expressions using JAXL. A typical DynaDTO mapping file looks like:

<?xml version="1.0" encoding="UTF-8"?>

 <dtos>

   <!-- *********************************************************** -->

   <!-- IChildDTO -->

   <!-- *********************************************************** -->

   <dto target="org.dynadto.samples.interfaces.IChildDTO"

        list="org.dynadto.samples.interfaces.ChildListDTO"

        useProxy="yes">

     <sources>

       <!-- *********************************************************** -->

       <!-- Child -->

       <!-- *********************************************************** -->

       <source type="org.dynadto.samples.domain.Child">

         <mapping property="index" />

         <mapping property="first" />

         <mapping property="last" /> 

       </source>

     </sources>

     <!-- *********************************************************** -->

     <!-- Comparator -->

     <!-- *********************************************************** -->

     <comparator useSuper="false" useReflection="false">

       <compare property="index" />

     </comparator>

   </dto>

 </dtos>

Sample usage:

// the 'domain' object

Child child = new Child("0", "Michael", "Sam-Bodden");

  

  // instantiate a builder for the DTO

Builder builder = BuilderFactory.getInstance().getBuilder(IChildDTO.class);

// use the builder to build the DTO

DTO myDTO = builder.build("child", child);

If you used Hibernate before you should be already familiar with how to use DynaDTO since we modeled it after Hibernate in terms of configuration and usage.

More examples see the examples page

Todos

• DTO ==> Domain functionality needs to be implemented. Currently this is a one way conversion tool.
• Cleanup Code. Refactor, refactor, refactor. For functionality, readability, O-Oness, performance, etc.
• Clean up TestNG tests
• Create a sample application (beside the Unit Tests)
• Create more documentation

Developer Weblogs

Brian Sam-Bodden Blog