WPF + REST+EF: как лучше организовать DTO?

У меня есть приложение WPF MVVM с 3 слоями:

  1. ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС
  2. Услуги
  3. ДАЛМАТИНЕЦ

и какой-то товар, например заказ. Мне нужно 3 DTO:

  1. Класс для слоя MVVM с уведомлением PropertyChanged;
  2. Класс для десериализатора Json (получение объектов с помощью REST API)
  3. Класс для Entity Framework (кэш данных в БД).

Ну, я могу использовать один класс для всех трех случаев, но это будет смесь различных атрибутов (от EF, JSon, MVVM) и избыточных зависимостей слоев.

Другой способ: создайте 3 класса, каждый слой имеет свой класс, и используйте AutoMapper для быстрого преобразования между ними. Не плохо, но 3 почти идентичные (90%) копии каждого класса DTO… не элегантное решение.

Каков наилучший подход? Что вы используете?
Спасибо.

1 ответ

  1. Каков наилучший подход? Что вы используете?

    Второй подход — определение бизнес-объектов в отдельной сборке, на которую можно ссылаться из всех приложений. Эти классы не должны реализовывать какие-либо клиентские интерфейсы, такие как INotifyPropertyChanged, но должны быть чистыми классами POCO, содержащими только бизнес-логику.

    В приложении WPF затем создается класс модели представления, реализующий интерфейс INotifyPropertyChanged и обертывает все свойства бизнес-объекта, которые имеет смысл предоставлять и привязывать из представления.

    Затем модель представления содержит ссылку на модель, а представление привязывается к модели представления. Это типично как шаблон проектирования MVVM (или должен быть) реализован в приложении WPF. Класс модели представления содержит логику приложения, например способ уведомления представления при изменении значения свойства привязки данных, а модель содержит бизнес-логику, одинаковую для всех платформ и приложений.

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

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