Moo maps an object or graph of objects to another object or set of objects while trying to stay as
unintrusive as possible and easy-to-use. Moo makes it possible to create quick copies and data
transfer objects.
There are a lot of ways you could use Moo -- to create data transfer objects, to work as an anti-corruption layer, to help summarize an object graph before serializing to XML or JSON. Examples of Moo at work can be found in the automated tests.
The simplest examples of how one might use Moo are:
Translate.to( UserDto.class ).from( currentUser ); Translate.to( UserDto.class ).fromEach( selectedUsers ); Update.from( userDto ).to( currentUser );
You can find more detailed examples in the User Guide.
You can download Moo, its source code and javadoc from the project's downloads page.
If you're using Maven, you can add a dependency on Moo. Stable releases are available in the Maven central repository, and snapshot versions can be found in the sonatype opensource repository.
If you want the entire project, you can download directly from GitHub in zip or tar formats.
You can also clone the project with Git by running:
$ git clone git://github.com/geoffreywiseman/Moo
Moo v1.2 (2010-Jan-11): Support for external objects in translation; this lets you bring in outside data or logic in the translation, which I needed to support a lookup against a data access object (DAO) in order to translate from a smaller client-side cached object to the real server-side domain object.
Moo v1.1 (2009-Nov-25): Support for access modes. Some of our DTOs flatten server-side hierarchies, and we wanted to be able to invoke setters rather than directly access the fields at times.
Moo v1.0 (2009-Nov-03): Initial release. After selecting Hibernate and GWT for a client project, we discovered they don't play very well together. I'd used an approach like Moo at several companies in the past, and it seemed worth doing again, but this time as an open source project, so I wouldn't have to do it ever again.
Although I've used Moo before and I'll undoubtedly use it again, I think it's still safe to say that the use of Moo is usually a sign that you have problems in your code and/or your architecture. Moo might be the best (most cost-effective, most palatable, etc.) solution to your problem, but I do suggest you sit back and take some time to ask yourself, "Why do I need to copy values from one set of objects to another set of objects?" "Do I really need parallel hierarchies?" "What problem am I solving, why do I have it, and is there a better way to go about it?"
Think of it this way: in the same way that the multi-stage digestion of ruminants, like cows (who say 'moo') allows them to extract nutrients from food that many of us consider indigestible (grasses), Moo may help you to extract value from an architecture that you consider indigestible. But if you can trade in your diet of grasses for something more pleasant and accessible, you probably should.
If you've evaluated your options, and you still think that Moo is the right solution, then by all means.
As much as possible, Moo is designed to be unintrusive. Although the current configuration requires annotations, the goal is for these annotations be used only within the lightweight summary objects you create for DTOs or for serialization. Eventually, it may be possible to configure Moo without using annotations.
The original concepts behind Moo were developed by Fuseboy first at Exchange Solutions, and then for The Syntegrity Group. Although this code is entirely new, Moo owes some conceptual debt to those implementations. Moo has been developed for open-source by Geoffrey Wiseman.
- Moo