BestPractice: за и против использования AutoMapper или LINQ (LINQ to Objects) для сопоставления между моделью домена и моделью презентации

Question

Как вы думаете? Как вы сопоставляете между вашим доменом и моделью презентации?

Answer 1

Цитирование части ответа от another Automapper question:

Если у вас есть объект одного типа, и вы хотите, чтобы заполнить свойство объекта другого типа, используя свойства от первого типа, у вас есть два варианты :

1. Вручную написать код, чтобы сделать такое отображение .
2. Используйте инструмент, который автоматически обработает это для вас.

AutoMapper является примером 2.

LINQ к объектам является примером 1 - это как раз случается быть немного менее болезненным, чем писать ванильный объект до объекта кода отображения.

С точкой зрения плюсов и минусов:

• Automapper должен значительно уменьшить объем кода, вы должны написать по сравнению с LINQ, как он использует соглашения для определения отображения по умолчанию. Используя LINQ, эти сопоставления по умолчанию должны быть определены.

• Используя LINQ, необходимо будет определить сопоставления в обоих направлениях - Automapper должен иметь возможность работать автоматически при использовании условных обозначений.

• Как и все сторонние DLL, использование Automapper представит другую зависимость и потребует небольшой кривой обучения (обратите внимание, что для тех разработчиков, которые раньше не использовали LINQ, также была бы кривая обучения).

Примечание, Automapper может быть использован в сочетании с LINQ (и LINQ2SQL) - yet another Automapper post, который объясняет некоторые тонкости.

Answer 2

http://bhavinsurela.com/linq-and-automapper-view-model-and-data-model/ может быть тем, что вы ищете.

Answer 3

Есть также недостатки в использовании AutoMapper, и некоторые из этих недостатков обычно применяются к программированию по соглашению (в отличие от написания кода явно).

Скажем, у вас есть два C# класса -

namespace MyDtoNamespace { 
    public class MyClass { 
     public int Id { get; set; } 
}} 

namespace MyBusinessLayerNamespace { 
    public class MyClass { 
     public int Id { get; set; } 
}} 

AutoMapper сопоставляются между этими двумя классами хорошо с небольшим количеством явной конфигурации требуется.

Но позже, скажем, разработчик рассматривает переименование одного из этих свойств идентификатора на что-то другое, например.

namespace MyBusinessLayerNamespace { 
    public class MyClass { 
     public int MyNewIdentifierVariableName { get; set; } 
}} 

Я тщательно искать ссылки в Visual Studio и рассмотрим влияние переименования этих ссылок - но потому, что MyDtoNamespace.MyClass.Id не явно ссылаться MyBusinessLayerNamespace.MyClass.Id, я никогда не видел его.

Когда Visual Studio или другой инструмент автоматически переименовывает все вхождения переменной для меня в решении, отображение AutoMapper ломается.

Я могу найти это только во время выполнения, нет проблемы с компиляцией. В идеале, у меня есть модульные тесты, чтобы проверить, работает ли мое отображение, но, тем не менее, вероятность ошибок во время рефакторинга является хорошей причиной для предпочтения написания явного кода преобразования.

Я, конечно, не спорю, чтобы избежать AutoMapper вообще, просто отметив, что основная проблема с программированием по соглашению.