Object Mapper с использованием репозиториев - PullRequest
Новая
       25

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

2 голосов
/ 28 января 2011

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

Я создаю n-уровневое веб-приложение, которое имеет слой репозитория и сервисслой и 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 с результатом.

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

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

1 Ответ

2 голосов
/ 28 января 2011

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

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

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

По своему опыту я столкнулся со следующим:

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

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

...