GeDA was inspired by developer's lazyness (as always). The rationale for its existance was overhead of creating DTO Assemblers in an n-tier application to pass information within domain object to UI through DTO's (Data Transfer Objects). The basic principle of the above application design is to extract the necessary information from the domain objects in the form of DTO's. In reality this involves a tidious get/set method calls that look very much the same for most of the objects. GeDA uses Java5's annotations in order to map DTO's onto paths of the Domain object properties (the reflection method). Thus the annotated DTO's can be examined by a Generic DTO Assembler that will create specific instance of the assembler for the DTO is respect to a Domain object. The assembler is basically a placeholder for so called "data pipes" that allow transferring data from/to domain object's field. But do not take my word for it - try it out yourself.

How does it work?

When coding user of this library uses java annotations or DSL registry to provide contextual information how DTO maps to an Entity

If you are following SOLID principles when you code then you would probably need to specify BeanFactory for Inversion of Control and Converter registry for doing tricky conversions between domain and DTO values

At runtime when a DTO assembler instance is created GeDA uses byte code generation library to generate adapter classes to transfer values between domain object and DTO model. This is to prevent use of java reflection which is quite slow. By default GeDA uses javassist to synthesize those classes but you have a choice of using BCEL or Sun JavaC using configurations.

Each assembler instance is also cleverly cached internally so that creation of assembler instances is brought to a minimum but does not clutter your memory (so no nasty OutOfMemoryException's).

As a result you have an awesome tool to transfer data between all sorts of java objects.

Furthermore GeDA 2.0.3 smoked all rival libraries on performance (Orika 1.2 which is supposed to be the fastest there is is twice as slow). Performance tests can be found here. Version 2.1.x are even better in terms of performance and memory consumption, and version 3.x.x is event better than 2.x.x. See test here

Version 2.x.x have full Spring v3.x.x support

Version 3.x.x have full OSGi support

Lastly is it a feature rich tool that allows to expand, flatten and combine your objects as well as handling complex mapping for collections and maps.

Minimal code contamination - use of GeDA usually means adding some annotations to your DTO bean and 3 extra lines of code in your service layer class

A true TDD library - our code is thoroughly tested using JUnit, Spring Test and Pax Exam, as well as various performance and benchmark tests using Caliper, Jetty and mutli threaded runners.

Common misconception: GeDA was not build to hydrate ORM classes (such as Hibernate). If you just want to get DTO with simple field values straight out of your DB you are better off with the Object Query Language (OQL) (such as HQL in Hibernate). However, if you are working in application service layer with complex view (as in MVC) then GeDA is just what the doctor ordered!

<!-- core module: use can you it on its own if you are not using Spring 3 --><dependency><groupId>com.inspire-software.lib.dto.geda</groupId><artifactId>geda.core</artifactId><version>3.1.0</version></dependency><!-- spring integration: spring 3 AOP wrapper for core --><dependency><groupId>com.inspire-software.lib.dto.geda</groupId><artifactId>geda.spring-integration</artifactId><version>3.1.0</version></dependency><!-- OSGi GeDA bundle --><dependency><groupId>com.inspire-software.lib.dto.geda</groupId><artifactId>geda.osgi</artifactId><version>3.1.0</version><type>bundle</type></dependency><dependency><groupId>org.apache.servicemix.bundles</groupId><artifactId>org.apache.servicemix.bundles.javassist</artifactId><version>3.12.1.ga_1</version><type>bundle</type></dependency>