Tell me more ×
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.
up vote 5 down vote favorite
1

Automapper is an "object-object mapper" for .Net, which means copying objects from a class into another class that represents the same thing.

Why is this ever useful? Is the duplication of classes ever useful/good design?

share|improve this question

1 Answer

up vote 7 down vote accepted

A quick google search revealed this example:

http://www.codeproject.com/Articles/61629/AutoMapper

showing a perfectly valid usage of AutoMapper which is definitely not an example for a poor design. In a layered application, you may have objects in your data or business layer, and you sometimes need just a subset of the attributes of that data objects, or some kind of view to them in your UI layer. So you create a view model which contains objects with exactly the attributes you need in your UI, not more, and use AutoMapper to provide the content of that objects with less boilerplate code.

In such a situation your "view objects" are not a duplicate of the original class. They have different methods and perhaps a few duplicate attributes. But that's ok as long as you use that view objects only for UI displaying purposes and don't start to misuse them for data manipulation or business operations.

Another topic you may read to get a better understanding of this is Fowlers Command Query Responsibility Segregation pattern, in contrast to CRUD. It shows you situations where different object models for querying data and updating them in a database make sense. Here, mapping from one object model to another may also be done by a tool like AutoMapper.

share|improve this answer
Regarding your first example: couldn't you compose objects instead of duplicating them? In that case your UI objects would have a reference to your original data objects, and would expose only the necessary elements. Wouldn't that make sense? – static_rtti Oct 3 '12 at 13:51
1  
@static_rtti in theory yes, but you may not necessarily want your original class to be public or/and exposed in an assembly – Jalayn Oct 3 '12 at 14:04
1  
@static_rtti: yes, that is a perfectly valid, different approach. The main difference between those two designs is the lifetime of the data/attributes. Using copies provides you with a snapshot of the data, using properties referencing the original data does not. Both approaches have its pros and cons, but IMHO there is no "better or worse" in general. Additionally, there may be performance considerations, which may or may not influence the decision what to use. – Doc Brown Oct 3 '12 at 14:06
2  
Decoupling as much as possible is always a good idea. Not because it's particularly beneficial for even small projects, but because projects grow. – fish Oct 3 '12 at 14:25
1  
@fish: I agree mostly, decoupling is often a good idea, but IMHO there are enough situations where keeping things simple outweighs a multi-layer-super-decoupled-for-the-sake-of-decoupling approach. The hard part is not to miss the point during the growth of a project when one should start refactoring. – Doc Brown Oct 3 '12 at 14:35
show 4 more comments

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.