Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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)

share|improve this question

3 Answers 3

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.

share|improve this answer
    
Yes, I can see benefit of automapping. I am just looking at Emit Mapper right now. Apparently it is as fast as manual mappers, which is nice improvement over AutoMapper. I like AssertConfigurationIsValid in AutoMapper though. –  Sebastian K Feb 8 '13 at 2:20

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.

share|improve this answer
    
I like te efficiency of this approach. One thing I like about automapper though, is that it allows you to check if you forgot to map somthing (Mapper.AssertConfigurationIsValid()) –  Sebastian K Feb 8 '13 at 2:18

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.

share|improve this answer
    
Interesting point about Clojure, I never given in a tty. Using same classes across the layers, could work in some cases, but it would be impractical with my technology stack. –  Sebastian K Feb 5 '13 at 17:48
    
Ya sorry, you listed all the conventional ways. This is the only other way I know of that doesn't require you to write a ton of code. –  mortalapeman Feb 7 '13 at 5:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.