# AutoMapper And Incompleteness

DevFeed: [AutoMapper And Incompleteness](<https://devfeed.tech/articles/automapper-and-incompleteness-33379.md>)

Original publisher: [Read original article](<https://timkellogg.me/blog/2011/09/15/automapper-and-incompleteness>)

Published: 2011-09-15T00:00:00Z

Content type: opinion

Language: en

Sources: [Tim Kellogg](<https://devfeed.tech/sources/tim-kellogg.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [implementation](<https://devfeed.tech/topics/implementation.md>), [domain](<https://devfeed.tech/topics/domain.md>), [unit tests](<https://devfeed.tech/topics/unit-tests.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [domain](<https://devfeed.tech/tags/domain.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [unit-tests](<https://devfeed.tech/tags/unit-tests.md>)

## AI overview

The article critiques AutoMapper for limiting mappings between view models and models, preventing view models from extending models, and encouraging duplicated properties and validation attributes. It proposes extending models with view models to reduce duplication and let the compiler catch certain mismatches, while acknowledging that this approach has other issues.

## Source excerpt

This is part 2 of a series. Read part 1Earlier I talked about the Law of Demeter and how view models help us better adhere to the Law of Demeter. I also briefly outlined how AutoMapper makes view models practical. While AutoMapper is a great tool, it isn't completely fulfilling. Let me explainAs I pointed out previously, some of the behaviors in AutoMapper make it feel incomplete. The first is that you can't map two view models to the same model and back.A much bigger problem with AutoMapper is that view models can't extend models. I'm not sure why they decided to disallow this usage, but it causes a cascade of code duplication (very un-DRY). Take a look at these classes:There are a few things wrong here. Age is a nullable int on the model but the view model has just an int. If a null slips through this could cause a crashing error. While AutoMapper has an AssertConfigurationIsValid method, it doesn't test for this sort of case. You'll have to make unit tests for this, luckily you can use NetLint to easily test for these sorts of flukes.Another issue is the validation attributes. The facts that account codes look like CO11582 and that all accounts must have a name are descriptors of the domain (which the model is modelling). They aren't facts about the view (although they have to be expressed in the view), they are part of the model. Every time you create another AccountViewModelX derivative AutoMapper requires you to copy these attributes. This is a massive failure in the attempt to keep code DRY.Another issue I have is when I'm creating a view model I'm not sure what properties need to be created. I usually have to split the window and copy properties from model to view model (this screams obscenities at the idea of DRY code).One solution that I keep coming back to is to have view models extend models. For instance, see this implementation:Here, you don't have to type out all those properties a second (or third) time. They're just available. You also won't make th