Is "Mapper" a valid design pattern or is it a variation of the "Factory" pattern?

Question

A common pattern I see is what's known as the Mapper pattern (not to be confused with DataMapper which is something else entirely), which takes as an argument some kind of "raw" data source (e.g. an ADO.NET DataReader or DataSet) and maps the fields to properties on a business/domain object. Example:

class PersonMapper
{
    public Person Map(DataSet ds)
    {
        Person p = new Person();
        p.FirstName = ds.Tables[0].Rows[0]["FirstName"].ToString();
        // other properties...
        return p;
    }
}

The idea being your Gateway/DAO/Repository/etc. will call into the Mapper before it returns, so you get a rich business object versus the underlying data container.

However, this seems to be related, if not identical, to the Factory pattern (in the DDD parlance, anyways), which constructs and returns a domain object. Wikipedia says this re: the DDD Factory:

Factory: methods for creating domain objects should delegate to a specialized Factory object such that alternative implementations may be easily interchanged.

From that quote the only difference I could think of is that the DDD-style Factory could be parameterized so it could return a specialized type of object if the need arose (e.g. BusinessCustomer versus ResidentialCustomer) while the "Mapper" is keyed to a specific class and only does translation.

So is there a difference between these two patterns or are they essentially the same thing with different names?

Answer 1

Although this is the first time I hear of the Mapper pattern, to me it sounds more like the Builder pattern rather than the Factory.

In the Factory pattern you encapsulate the logic for creating objects of a number of related classes. The prime example would be a situation where you need to create an object of a particular subclass of some abstract base class depending on some parameters. So a Factory always returns a pointer or a reference to the base class, but it actually creates an object of the appropriate derived class based on the parameters you give it.

In contrast, a Builder class always creates objects of the same class. You would use it if the creation of an object is complicated, e. g. its constructor takes lots of arguments, not all of which may be available instantly. So a builder object might be a place which stores the values for the constructor arguments until you have them all and are ready to create the "product", or it may provide reasonable default values and let you only specify the arguments whose values you need to change. A typical use case for the Builder pattern is for creating objects you might need in a unit test, to avoid cluttering the test code with all the creation logic.

To me a Mapper sounds like a variant of a Builder, where the constructor parameters come in the form of a database record or some other "raw" data structure.

Answer 2

As I look over the answers I see the respondents all providing semantically incorrect answers. I think this is because you are all too focused on the question, which is focused on how mapper is related to factory or builder.

When in fact Mapper is NOT akin to factory or builder. Mapper is most like the adapter pattern (using GoF parlance). The adapter pattern provides functionality for converting one representation into another. The OP referred to the DataSet and the DataReader in ADO.NET-- well how about the SqlDataAdapter? The answer is in the name. Mapper is a new name for something that older programmers have known about for a long time: adapters.

Mapper converts one representation into another-- the very definition of the adapter pattern.

Answer 3

The only common thing about Mapper, Builder and Factory is that they deliver a "constructed product" - an object instance of a type. To avoid any confusion, I am referring to following discussions for their respective definition.

1. Mapper - close to what is explained here: http://www.codeproject.com/KB/library/AutoMapper.aspx. This is not exactly the same as above - but the closest I found about Mapper.

2. Builder - as defined here: http://www.oodesign.com/builder-pattern.html

3. Factory - is defined here: http://www.oodesign.com/factory-pattern.html

The Mapper is essentially a constructor inside out. Suppose for a while, if you don't have a Mapper - when you need many seta of parameters they are all arguments on the constructor. Now as things evolve, some applications are not aware of additional attributes that needs to go under constructor where one either computes it or use default. The critical thing is that Mapper can do this for you - and it would be more useful if this has linkage to external objects to decide such an algorithm for construction.

The Builder is very different from Mapper. A Builder is essential when a complete object is composed using many parts of the object. It's kind of assembling the objects by fitting together many parts. Even the initialization of the individual part objects are related to existence of other parts.

The Factory patterns looks very simple at the outset. It returns a newly constructed objects. If any ordinary constructor can give me a fully functional instance using an operator like new()? why would I need a Factory that gives me the same results?

However, the Factory pattern's usage is typically very specific; though most often, not displayed in literature where this is applied. Usually, an application creates a Factory which is shared to various objects who needs to create such product objects during the execution. When many such products are created, the Factory method allows creation of objects based on certain policy for example, one can force a certain template which is used by Factory method when all objects are created. This is neither like a Builder method; here product out is only one (and independent). This is also not like Mapper; here the external data set to create the object as per the client is actually minimal. The Factory pattern really provides (as the name suggests) consistently similar product objects!

Answer 4

the answer to your question : Is “Mapper” a valid design pattern ? is yes. Mapper pattern, is also known like Translator Pattern and is a documented pattern : http://www.iro.umontreal.ca/~keller/Layla/translator.pdf

Answer 5

What your are doing here is actually some kind of type conversion (you convert your raw data into a business object). You can use the Factory Pattern for doing exactely that (i.e., type conversions), so yeah, in some kind of way, your class is a factory (though I would use a Static Factory for that).

Answer 6

Builders encapsulate complex business logic to build an object. Mapper on the other hand should just copy the fields from one to another.

For example map from Database Employee Object to Domain Employee Object, map from Domain Employee Object to Client Contract.

Builders on the other hand host multiple business decisions to build an object. From Single Responsibility point of view, this makes sense.