BestPractice: за и против за использование AutoMapper или LINQ (LINQ to Objects) для сопоставления между моделью предметной области и моделью представления - PullRequest
2 голосов
/ 14 апреля 2010

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

Ответы [ 3 ]

3 голосов
/ 15 апреля 2010

Цитирование части ответа от другого вопроса Automapper :

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

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

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

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

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

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

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

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

Обратите внимание, Automapper может использоваться вместе с LINQ (и LINQ2SQL) - еще один пост Automapper , который объясняет некоторые тонкости.

2 голосов
/ 07 февраля 2017

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

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

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

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

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

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

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

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

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

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

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

1 голос
/ 30 января 2012

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

...