Использование сервиса graphql в настольном приложении, которое «следует» за MVVM и DDD - PullRequest
Новая
       19

Использование сервиса graphql в настольном приложении, которое «следует» за MVVM и DDD

0 голосов
/ 07 мая 2019

У нас есть настольное приложение WPF, которое использует шаблон MVVM и DDD (ну, скажем, по крайней мере, мои классы моделей, которые хранят данные, названные объектами, взятыми из реального мира).Приложение использует несколько микросервисов через REST API.И это сработало отлично.Пока мы не подумали, что пришло время использовать какой-то фасад для серверной части, чтобы объединить все эти микросервисы и получить только те данные, которые нам нужны для определенного экрана.

НО.Вопрос в том, как заставить их жить вместе.

  • С одной стороны, мы динамически возвращаем данные из graphql.Это
    означает, что, например, если у нас есть список людей на одном экране, мы будем запрашивать идентификатор, имя, фамилию и роль человека.На другом экране
    для выпадающего списка людей мы будем запрашивать те же данные, но без роли.
  • С другой стороны, у нас есть класс Person, у которого есть статический набор полей Имя, Фамилия, Роль и Id, который человек имеет в «реальной жизни»

Если мы используем один и тот же класс Person с graphql, , преобразовывающий данные из JSON в модель Person, оба экрана будут работатьхорошо, но за кулисами один экран, которому не нужна роль , не запросил бы его у graphQL .И у нас будет ситуация, когда у модельного класса Person будет поле Role, но оно будет просто пустым (а это, я думаю, отчасти пахнет. По крайней мере, я не думаю, что такой код будет легко поддерживать)Разработчик должен добавить некоторую информацию на экран, открыть модель, увидеть, что Роль там, привязать поле к экрану и пойти выпить кофе. И затем, к сожалению, есть поля, но не было назначено данных ).

У меня на уме два варианта:

  • либо не использовать модели и DDD, но и отображать данные напрямую в ViewModel (что лично для меня похоже на разрушение всего, что у нас было)раньше).
  • или мы отобразим эти динамические данные в наши существующие модели и различные поля для разных экранов (например, для одного и того же класса Person) будут пустыми (потому что не запрошены).

Может быть, кто-то уже использовал такую ​​комбинацию.Как вы его используете и каковы плюсы и минусы?

1 Ответ

0 голосов
/ 07 мая 2019

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

Не существует абсолютного «наилучшего» решения, независимо от того, какое влияние окажет полный набор столбцов на производительность. Что, в свою очередь, может быть связано с такими вещами, как кэширование.

Вы можете написать службы, которые возвращают подмножества данных, и тогда вы используете только необходимую пропускную способность. Сортировка по шаблону CQRS, но, возможно, с большим количеством моделей, чем просто чтение + запись.

Часто в этом нет необходимости, а возникшие осложнения не компенсируют увеличение стоимости обслуживания.

То, что часто делается, это просто отобразить модель на модель (и обратно). Модель представления, которой требуется всего 4 столбца, просто имеет 4 свойства, и все, что возвращается моделью, не копируется. Модель представления, которой необходимо 5, имеет 5 свойств, и они скопированы из модели.

...