-
Notifications
You must be signed in to change notification settings - Fork 8
Use Cases
These are some of the areas where Moo has proved useful.
If your project has a domain layer and a data-transfer-object layer, there will often be a lot of common elements between these two, and manually copying information from the one to the other can be a real pain and prone to error. Moo can automate that process and reduce errors.
In practice, if you can avoid having two parallel hierarchies like a domain layer and a DTO layer, this is often a better solution that automating the translation between the two. It's not always avoidable.
If you have a graph of domain objects and you'd like to serialize part of that graph to be transferred to another system, it might be that the serialization mechanism lacks the necessary controls to allow you to filter that serialization to a subset of objects/properties. In this case, you can write your own summary objects and use Moo to carry the data from the domain to the summary objects.
Again, if you can control the serialization layer sufficiently or switch serialization mechanisms to avoid the need to create summary objects, this might be a better choice, but if you can't, then Moo is a reasonable solution.
If you're using Moo in a very different way, I'd be interested to hear more. Drop me a line.
- Five Minute Introduction
- Getting Moo
- Translating Object Properties
- Translating Collection Properties
- Translating Map Properties
- Source Expressions
- Access Modes
- Translating to Value Types
- Extensions
- External Objects in Translation
- Ignoring Properties
- Updating Collections
- Translation Target Factories
- Nested Updates
- Optional and Required Properties
- Order of Property Translation
- Constructors
- Lookup on Update
- Caching
Releases
Background