When to Use Which Mapping Strategy?

This is the million-dollar question.

The answer is the usual, dissatisfying, “it depends”.

No hard-and-fast rule

Since each mapping strategy has different advantages and disadvantages, we should resist the urge to define a single strategy as a hard-and-fast global rule for the whole codebase. This goes against our instincts, as it feels untidy to mix patterns within the same codebase. But knowingly choosing a pattern that is not the best pattern for a certain job just to serve our sense of tidiness is simply irresponsible.

Software evolution

Also, as software evolves over time, the strategy that was the best for the job yesterday might not still be the best for the job today. Instead of starting with a fixed mapping strategy and keeping it over time no matter what, we might start with a simple strategy that allows us to quickly evolve the code and later move to a more complex one that helps us decouple the layers in a better manner.

In order to decide which strategy to use when, we need to agree upon a set of guidelines within the team. These guidelines should dictate which mapping strategy should be the first choice in which situation. They should also answer why that mapping strategy is the first choice so that we’re able to evaluate if those reasons still apply after some time.

We might, for example, have different mapping guidelines for modifying use cases than we do for queries. Also, we might want to use different mapping strategies between the web and application layers and between the application and persistence layers.

Guidelines