Good practices to implement mappers in a multi-tier application

Question

When you are working with a multi-tier application very often you run into task of converting objects in one layer to objects in another layer. This could be converting database objects into domain objects, service objects into domain objects, domain object into view models, etc.

I've seen it being done in multiple ways, those include:

1. In-line conversion
2. Creating a translator class with static helper methods
3. Using extension methods to simplify conversion
4. Overriding cast operators
5. Creating sepearate mapper classes for every possible translation
6. Utilizing solutions such as automapper

What would be the "proper" way to handle it. The application I currently work with utilizes separate mapper class for every possible translation, and although it has benefits of testability we are using dependency injection and we have to pass all those mappers as dependencies in the constructor.

Has anybody figured out a better way to do it?

UPDATE

I am using .NET stack here (EF +Business Layer + MVC)

Answer 1

I'm not sure about the best way to implement object-object mapping, but you may prefer to rely on a library specially created to solve that. My project is also based in the .NET stack and Automapper (http://automapper.org) works great. It's available via NuGet.

Answer 2

AutoMapper is a common solution for this, however I prefer to hand-code the mappings. I usually have a static class with extension methods which maps to and from DTOs.

[DataContract]
class UserDto
{
 [DataMember]
 public string Name { get; set; }

 [DataMember]
 public DateTime BirthDay { get; set; }
}

class User
{
  public string Name { get; private set; }
  public DateTime BirthDay { get; private set; }
}

static class ContractMappings
{
   public static UserDto ToDto(this User user)
   {
     return new UserDto
     {
       Name = user.Name,
       BirthDay = user.BirthDay
     };
   }
}

Each project at application boundaries will have a ContractMappings class which contains mappings for all contracts associated with that project. If this class gets too big it may be a sign that the project boundaries are invalid.

Hand-coded mappings allow a greater degree of flexibility, which may be both an advantage and a disadvantage.

In case of ViewModels, I usually have the ViewModel accept a DTO or domain object in its constructor. If the ViewModel is used for creating a DTO or updating a domain object, I put the update method directly in the ViewModel to maintain the highest degree of cohesion.

Answer 3

The answer is, the solution that best solves your problem domain. Below is another solution that you didn't mention.

Use the same type for all models. Most objects you are using to store data can be viewed as a hashmap or a dictionary. The name of the property is the key and returned value is the value. Clojure is an excellent example of a language that supports this line of thinking with the use of keywords. Keywords are a word or phase that begin with a colon and can be used as a descriptive identifier. In Clojure, a map is a function that can take a key as an argument and return its paired value.

(def my-data-model { :name "Joe" :age 25 })
(my-data-model :name) => "Joe"

If your domain model looks like this:

(def domain-model { :id 1 :value "my data" })

Your view model might just be the same thing with the :id key/value pair removed. With this approach, all of your "models" are the same type and there is no need to translate between them.