Object Mapper с использованием репозиториев

Я хочу знать, является ли плохой дизайн использовать репозитории при преобразовании DTO в их аналог объекта домена.

Я создаю многоуровневое веб-приложение, которое имеет уровень репозитория, уровень обслуживания и ef4 для ORM. Уровень сервиса предоставляет DTO-версии объектов домена. Когда я получаю DTO от потребителя службы, служба будет использовать AutoMapper для преобразования DTO в объект домена. Теперь некоторые свойства членов в объекте домена необходимо будет загрузить из базы данных, например, у меня есть класс ниже -

Версия DTO:

public class LogonEventDto
{
    public DateTime Time
    {
        get;
        set;
    }

    public Guid UserId
    {
        get;
        set;
    }
}

Версия домена:

public class LogonEvent
{
    public DateTime Time
    {
        get;
        set;
    }

    public User User
    {
        get;
        set;
    }
}

Теперь, когда дело доходит до преобразования DTO в версию DO, мне нужно будет вызвать метод GetById () в UserRepository и установить свойство LogonEvent.User с результатом.

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

Итак, как я спросил выше, является ли это плохим дизайнерским решением, и если да, то почему?


repository c# automapper dto
person jameskind    schedule 28.01.2011    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Я считаю, что поступать так - это разумно. Вы отделяете представление внутреннего состояния (модель предметной области) от контракта на обслуживание (контракты dto / data). Таким образом, вы не открываете какие-либо внутренние компоненты и можете провести рефакторинг своей реализации, не затрагивая контракт на публичную службу (при условии, что сопоставление все еще возможно).

мы все время используем этот шаблон в наших проектах клиентов SOA (-isch). У нас даже есть инструмент, который поможет вам сгенерировать код отображения.

Я не поклонник AutoMapper (хотя код очень крутой), потому что он требует, чтобы вы указали сопоставление во время выполнения (вам нужно написать код для создания определения сопоставления). На мой взгляд, определение сопоставления - это вопрос времени разработки. Вот почему мы создали инструмент-генератор кода.

По своему опыту я встречал следующее:

  • Не извлекайте данные (по идентификатору) для каждой записи отдельно. Вместо этого соберите список идентификаторов, которые вы хотите разрешить за один цикл (к базе данных / источнику данных / другой веб-службе), и позвольте сопоставлению просто выполнить поиск в полученном пакете.
  • При сложных сопоставлениях с множеством объектов и различными иерархиями классов между источником и целью трудно вести обзор того, что вы сопоставили, где и как. Для этого пока нет реального решения - кроме создания инструмента, который поможет вам в этом.

Надеюсь, поможет. Grtx, Марк

person obiwanjacobi    schedule 28.01.2011