Использование MVVM и DDD в приложении WPF без слишком большого количества классов

wpf design-patterns mvvm architecture domain-driven-design

4175 просмотра

3 ответа

250 Репутация автора

У меня есть приложение WPF, в котором я хочу применить MVVM для уровня представления и DDD для всего приложения. Я очень смущен тем, как я должен применять архитектуру. Можете ли вы дать мне несколько советов, так как на данный момент я полностью запутался со следующей попыткой разработки:

У меня 4 слоя:

  • Presentation Layer : Здесь находится мое клиентское приложение WPF.

  • Application Layer: Здесь у меня есть свои сервисы, которые должны взаимодействовать с доменными сервисами по бизнес-правилам и работают с CRUD. Он работает просто как слой антикоррупционного между Presentationи Domainслоев.

  • Domain Layer : Здесь у меня есть агрегаты, доменные объекты и некоторые сервисы, раскрывающие бизнес-правила, такие как IsTooOld(Person person)

  • Infrastructure Layer: Это самый нижний уровень, инфраструктура лежит здесь IRepositoryи IEntityт. Д.

Давайте реализуем простой сценарий с этими слоями на основе DDD: поместите объект Person в базу данных, сопоставьте его, CRUD базу данных, проверьте день рождения людей и покажите его пользователю.


Уровень представления

Я начну с части WPF. Я создаю следующие классы:

  • PersonView : XAML взгляд на человека

  • PersonViewModel: ViewModelэто обеспечивает функциональность для PersonView. PersonViewпривязывается к этому, и это ViewModelобеспечивает значения отPersonModel

  • PersonModelЭто модель MVVM, с которой я PersonViewModelтесно связан.


Уровень домена

Это достаточно хорошо для уровня представления. Теперь я хочу подключиться к базе данных, чтобы получить объект person для его представления.

Я должен создать:

  • PersonEntityin Domain Layer: агрегат для объекта базы данных, используемый для сопоставлений с базой данных. Он лежит в Domainслое.

  • Personв Domain Layer: Это доменная модель DDD. Я приведу здесь некоторую логику, и я не хочу отправлять объекты-сущности, как предлагает DDD.


Уровень приложений

Хорошо, у меня уже есть 3 человека модели, которые очень похожи друг на друга. Как насчет еще доступа к данным и услугам?

  • PersonServiceв Application Layer: Когда мой уровень представления хочет связаться с этим уровнем, он должен преобразовать его PersonModel(модель MVVM) в Person(модель предметной области). Затем этот сервис на прикладном уровне преобразует Person(модель домена) в PersonEntity(объектный объект) и выполняет CRUD с базой данных. Эта служба использует также другой PersonService(см. Ниже) на уровне домена для проверки / применения некоторых бизнес-правил.

  • PersonServiceв Domain Layer: Этот слой работает только с Personдоменным объектом. Это имеет связанные с бизнесом правила, такие как bool IsTooOld(Person person).


Подводя итог, я получил 7 классов для простого сценария:

  1. Presentation.WpfClient.View.PersonView
  2. Presentation.WpfClient.ViewModel.PersonViewModel
  3. Presentation.WpfClient.Model.PersonModel
  4. Application.ApplicationServices.PersonService
  5. Domain.Application.Services.PersonService
  6. Domain.Application.Models.Person
  7. Domain.Application.DbEntities.PersonEntity (причина, по которой я это создал, заключается в том, что я не могу использовать сопоставление для сложных объектов домена, поэтому я просто помещаю здесь некоторые аннотации данных вместо сопоставления объектов домена)

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

У меня все еще есть два конкретных вопроса:

  1. Следует ли удалять модели из уровня представления (модели MVVM) и использовать только модели из уровня домена (модели DDD)? Разве это не нарушение MVVM на данный момент?

  2. Должен ли я объединить мои модели сущностей (базы данных) с моделями доменов? Разве это не нарушение DDD?


Обновить

Решения, которые я принял:

  • Использовать модель предметной области для модели MVVM (удалено PersonModel)
  • Используйте внешние сопоставления для той же модели с базой данных (удалены PersonEntityдобавленные PersonMappings). Использование модели постоянства намного дороже, чем простое отображение. См. Http://enterprisecraftsmanship.com/2016/04/05/having-the-domain-model-separate-from-the-persistence-model/ из ответа Владимира.

Наконец это выглядит так:

  1. Presentation.WpfClient.View.PersonView
  2. Presentation.WpfClient.ViewModel.PersonViewModel
  3. Application.ApplicationServices.PersonService (с некоторой логикой, связанной с приложением)
  4. Application.ApplicationServices.Mappings (У меня есть репозиторий абстракции и сопоставления здесь)
  5. Domain.Application.People.Person (объект person в его ограниченном контексте, объект достаточно умен, чтобы обрабатывать логику домена)
Автор: U. Bulle Источник Размещён: 18.07.2016 07:40

Ответы (3)


1 плюс

1233 Репутация автора

По первому вопросу, использование моделей доменного уровня в качестве моделей MVVM не является нарушением MVVM ( см. Определение модели здесь )

Для более подробной информации по теме и ответу на ваш второй вопрос см. Это: Entities VS Domain Models VS View Models

Автор: Timothy Ghanem Размещён: 18.07.2016 09:10

2 плюса

491 Репутация автора

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

  1. В большинстве случаев речь идет о данных CRUD с небольшим изменением структуры данных. Я бы использовал только:

    Уровень представления: ViewModel
    Уровень обслуживания: ViewModel <-> объект Domin
    Уровень домена: объект домена совпадает с объектом

  2. Для более сложного домена, где есть много важной и многократно используемой бизнес-логики для объекта Domain, я бы добавил базовую службу (например, Domain.Application.Services.PersonService).

  3. Если есть также сложная бизнес-логика, необходимая для данных процесса, для более простого отображения данных между слоем представления и уровнем Домина. Я бы добавил еще одну модель в Service Layer, аналогичную вашей Presentation.WpfClient.Model.PersonModel.

Таким образом, в основном архитектура, которая у вас есть сейчас, готова к тому, что ваш домен Person очень сложен в вашем проекте. Но я не могу видеть это так далеко от вашего описания.

Чтобы ответить на ваши вопросы:

  1. Вы можете удалить Presentation.WpfClient.Model.PersonModel в ваших моделях MVVM. Это не нарушает MVVM, потому что в этом случае ваш доменный объект является моделью, а у вас Presentation.WpfClient.ViewModel.PersonViewModel как ViewModel.

  2. Вы можете объединить Entity с объектом Domain, если ваш домен Person не имеет сложной бизнес-логики.

Автор: codigube Размещён: 19.07.2016 10:32

11 плюса

1163 Репутация автора

Решение

Это слишком много классов для одной концепции.

Следует ли удалять модели из уровня представления (модели MVVM) и использовать только модели из уровня домена (модели DDD)? Разве это не нарушение MVVM на данный момент?

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

Должен ли я объединить мои модели сущностей (базы данных) с моделями доменов? Разве это не нарушение DDD?

Также да. Разделение сущности на две части (сущность домена и сущность «постоянство») обычно приводит к чрезмерному усложнению и анемичной модели предметной области. Вот еще об этом: Отделение модели предметной области от модели постоянства .

В целом, я рекомендую вам взглянуть на этот пример. Это выглядит как раз то, что вам нужно: полноценное приложение, написанное на WPF с использованием MVVM и DDD.

Автор: Vladimir Размещён: 21.07.2016 09:01
Вопросы из категории :
32x32