Как использовать DTO между UI, BLL, DAL

Question

Я пытаюсь написать небольшое приложение с очень строгими границами между BLL и DAL, и теперь мне интересно, как лучше всего передать данные (объекты передачи домена) между слоями.

Я реализовал некоторые классы на уровне домена (библиотека классов), доступ к которому имеют как BLL, так и DAL. Эти классы в основном просто содержат свойства / элементы данных и в настоящее время отражают данные DAL. Пример:

class CustomerData
{
  // some data fields
}

Затем я реализовал некоторые классы в BLL как:

class Customer : CustomerData
{
  // Some methods
}

В моем DAL я получаю записи клиентов из базы данных через Linq-to-Sql. Затем я сопоставляю объект linq своему объекту Domain следующим образом:

CustomerData.field = LinqObject.field
// Etc

Таким образом, я думаю, что теперь я получаю экземпляр CustomerData из моего DAL в BLL по запросу (и я должен передать экземпляр Customer в свой пользовательский интерфейс).

Таким образом, в моем BLL я получу экземпляр CustomerData, но теперь я хочу сделать из него Customer.

Вопросы:

1. Нужно ли в моем BLL сейчас создавать экземпляр Customer и ОПЯТЬ копировать всех членов поля?
   Клиент c = новый клиент; c.field = CustomerData.field;
2. Как я могу создать клиента из CustomerData без шагов копирования поля?
3. Стоит ли мне использовать композицию?
   класс клиента { Данные CustomerData; }
4. Есть ли более эффективный способ (меньше кода и т. Д.) Сделать это в моем текущем макете?
5. Есть ли лучшие способы сделать это?
6. Есть какие-нибудь комментарии вообще?

Спасибо!

Answer 1

Как правило, я считаю, что DTO не зависят от слоя, создаются / потребляются DAL, обрабатываются BLL и потребляются / создаются пользовательским интерфейсом.

обычно каждый слой - это отдельный проект в папке решения VS, поэтому DTO - это еще один проект, на который ссылается каждый слой.

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

Answer 2

Некоторые заметки с моей точки зрения приходят сюда, я не оракул, но, надеюсь, это поможет:)

Мне кажется, что у вас здесь слишком много "моделей". Это может вызвать путаницу и привести к большому количеству кода только для копирования данных между различными представлениями. И много кода означает больше ошибок. Затем я думаю, что наследование между вашими классами данных и бизнес-классами ограничивает вас при определении ваших бизнес-классов. Как насчет того, чтобы создать бизнес-класс, состоящий из нескольких классов данных? Вам лучше использовать интерфейсы или композицию, я думаю.

Обычно я работаю только с одной концептуальной моделью, отражающей сферу бизнеса. Эта модель используется как на уровне данных, так и на бизнес-уровне, а в некоторых случаях даже на уровне представления (в небольших приложениях), как отмечает Dead Rabit. Для устойчивости я использую O / RM, такой как EF 4.

Для более крупных проектов, особенно в распределенных сценариях, я использую собственные DTO для UI-слоев. Эти классы отражают потребности пользовательского интерфейса и могут сильно отличаться от сущностей в концептуальной модели.

Лично я думаю, что Entity Framework 4 очень поможет вам при создании приложений в соответствии с этой структурой. Если вы находитесь на ранней стадии своего проекта и используете .NET 4, вы можете попробовать его?

1. Да, вам, вероятно, нужно.
2. Использовать композицию
3. Да, я бы использовал композицию
4. Используйте, например, Entity Framework 4
5. (- "-)
6. см. Выше

Answer 3

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

CustomerData customerData = Mapper.Map<LinqObject, CustomerData>(linqObjectInstance);

Вы также должны взглянуть на шаблон PresentationModel: http://martinfowler.com/eaaDev/PresentationModel.html

Вы также можете использовать Google для MVVM (Model-View-ViewModel), если хотите пойти по этому пути.

Answer 4

вы не полностью используете DTO. В своем классе Customer верните CustomerData непосредственно в свой пользовательский интерфейс.

и нет необходимости наследовать Customer от CustomerData

EDIT: Я полностью использовал это слово, потому что CustomerData - это DTO, поэтому вместо возврата Customer верните CustomerData, поскольку это ваш DTO, как показано на следующей диаграмме.

Одно предложение: вам следует использовать Шаблон репозитория для изоляции ваших BLL и DAL.

1]