2017-02-14 6 views
1

Я был бы признателен за небольшую помощь здесь ...картограф Object против обертки объекта

Допустит, что в приложении мы имеем уровень данных и бизнес-логику. В DAL мы имеем следующую сущность:

public class Customer { 
    public string Name {get; set;} 
    public ICollection<Address> Addresses {get; set;} 
} 

public class Address { 
    public string Street {get; set;} 
} 

В УСКЕ мы следующий POCO которые:

public class CustomerDto { 
    public string Name {get; set;} 
    public ICollection<AddressDto> Addresses {get; set;} 
} 

public class AddressDto { 
    public string Street {get; set;} 
} 

Субъекты в DAL заселены с Светло-весом ОРМОМ и извлечь из УСКА используя репозиторий. Пример:

public class CustomerInformationService { 

    private readonly ICustomerRepository _repository {get; set;} 
    public CustomerInformationService (ICustomerRepository repository) 
    { 
     _repository = repository; 
    } 
    public class CustomerDto Get(int id) 
    { 
     var customerEntity = _repository.Get(id); 

     var customerDto = /* SOME TRANSFORMATION HERE */ 

     return customerDTO; 
    } 
} 

Мои вопросы касательно/* НЕКОТОРЫЕ ПРЕОБРАЗОВАНИЯ ЗДЕСЬ */part. В нашей команде обсуждается, как делать «картографирование».

Один из подходов состоит в том, чтобы использовать устройство сопоставления либо автопарпер, либо ручное сопоставление. Второй подход заключается в том, чтобы использовать как обертку вокруг Entity и ссылаться на DTO, чтобы сохранить операцию копирования между объектом. Что-то вроде этого:

public class CustomerDto 
{ 
    private IEntity _customerEntity; 

    public IEntity CustomerEntity { get {return _customerEntity;}} 

    public CustomerDto(IEntity customerEntity) 
    { 
      _customerEntity = customerEntity; 
    } 

    public string Name 
    { 
      get { return _customerEntity.Name; } 
    } 
    public ICollection<Address> Addresses 
    { 
      get { return _customerEntity.Addresses; } 
    } 
} 

Второй подход чувствует себя немного странно для меня, потому что _customerEntity.Addresses чувствует себя как утечка (ссылка _customerEntity в) между моей DAL и моей УСК, но я не уверен.

Есть ли какие-либо преимущества/недостатки использования одного подхода над другим?

Дополнительная информация: Обычно мы тянем максимум. из 1000 записей одновременно, которые необходимо преобразовать между Entity и DTO.

+1

Если вы собираетесь использовать подход обертки, вы можете просто использовать сущности и забыть об использовании объектов dto. Вы не покупаете ничего с оберткой, но добавляете жесткую связь и другую зависимость. – dbugger

+0

@dbugger - спасибо за ответ. Какую зависимость вы имеете в виду? BLL всегда знал интерфейсы от DAL, независимо от того, как мы используем mapper или wrapper для создания DTO. –

ответ

0

Вы не упомянули свою «весовую ОРМ». Я отвечу в двух разделах.

Если вы используете ORM, который создает прокси

Вы должны избегать воздействия сущностей за пределами определенной границы. ORM, такие как NHibernate/EF, реализуют ленивую загрузку на основе прокси. Если вы обнаружите объекты на уровне приложения/UI, у вас будет мало контроля над поведением ORM. Это может привести к множеству неожиданных проблем, и отладка также будет очень сложной.

Упаковочные объекты в DTO ничего не получат. В любом случае вы получаете доступ к объектам.

Использование DTO и отображение их с помощью некоторого инструмента отображения, такого как AutoMapper, является хорошим решением здесь.

Если вы используете ORM, который не создает прокси

НЕ используйте DTOs, непосредственно использовать свои объекты. DTO полезны и рекомендуются здесь во многих случаях.Но пример, который вы поставили под вопрос, вообще не нуждается в DTO.

Если вы решили использовать DTO, обертывание объектов в DTO не имеет смысла. Если вы хотите использовать Entity в любом случае, зачем его обертывать? Опять же, инструмент, такой как AutoMapper, может помочь.

См. Вопросы this. Это немного другое; Я прошу Да/Нет и вы спрашиваете Как. Но все равно это поможет вам.

+0

Спасибо A_J. Потребовалось некоторое время для обсуждения, но различия между ORM с прокси и без прокси помогли нам много. В нашем случае ORM не генерировал прокси-серверы, но сущности нуждались в специальных атрибутах, чтобы ORM мог их сопоставлять. Поскольку мы не хотели раскрывать эти атрибуты в других слоях, мы закончили их обертку в DTO и использовали automapper. –

0

Держу пари на подход к уровню обслуживания. В основном потому, что что-то, что похоже на бизнес-объект или доменный объект не имеет ничего общего с DTOs.

И, на самом деле, вы и ваша команда должны использовать AutoMapper вместо того чтобы повторять одни и те же кодовые тонны времени, который будет состоять в установлении некоторых свойств от А к В, от А до С, С к В ...

+2

На самом деле, для меня ручное сопоставление в большой базе кода может быть только симптомом синдрома [гордый разработчик] (http://designpattern.ninja/catalog/anti-design-patterns/proud-developer)! –

Смежные вопросы