Архитектура приложения мобильных приложений Azure

Question

Я пытаюсь объединить архитектуру для Windows Universal App, используя Azure Mobile Services. Это приложение LOB, и вам нужно будет обрабатывать 100-250 офлайн-онлайн-таблиц. В настоящее время Mobile Services не поддерживает вложенные сложные объекты, поэтому на стороне службы я сопоставил большинство своих таблиц прямо из структуры сущности.

Вопрос, который у меня есть, заключается в том, должен ли я использовать отдельный слой для восстановления DTO или если я должен делать это через уровень обслуживания и модель представления. Моя основная проблема заключается в изоляции ответственности (большая команда) и накладных расходах от дополнительного картографирования.

У меня нет репутации для добавления изображения здесь ссылка на модель.

Примером может быть человек, объект с набором адресов прилагается. У меня есть три объекта DTO: один для человека один для адреса и один для отношений многих и многих. Если я перехожу к модели представления, мне понадобится служба адресации для поиска адреса для конкретного человека.

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

Answer 1

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

Причина, по которой производится сопоставление с DTO, точно так же, как вы сказали: прямой связи между объектами в Azure Mobile Services нет. Это по дизайну, чтобы обеспечить простую модель взаимодействия между клиентом и сервером, но это может означать больше дизайна, когда модель данных связана с отношениями.

В целом, мы рекомендуем следующее:

1. Если у вас есть 1: много отношений, где Существует явная собственность отношения между родителями и детьми, как правило, лучше, чтобы отобразить дочерние объекты в родителю , Это также упрощает случай, когда мобильный клиент создает новые дочерние объекты и связывает их с родителем. Независимый протокол синхронизации отправляет изменения индивидуально, поэтому объекты должны быть сгруппированы вместе, если они должны быть одним атомарным действием. Пример этого см. В разделе FieldEngineerLite sample.

2. Если у вас есть 1: много отношений, и не важно напрямую запрашивать дочерние объекты, вы можете либо отобразить как в # 1, либо создать отдельные контроллеры таблиц для детей и управлять отображением с помощью внешних ключей.

3. Для многих: многие отношения, это обычно добавляет слишком много сложностей, чтобы напрямую разоблачить таблицу отношений. Здесь рассмотрим сглаживание идентификаторов объектов в одном из объектов. В вашем примере DTO клиента может иметь список идентификаторов адресов, а адреса находятся в их собственной таблице на клиенте.

Если вы решите сделать вариант № 3, ваш код должен убедиться, что все соответствующие адреса отправлены клиенту. Вы можете либо a) перейти к сплюснутому объекту, а затем распаковать на стороне клиента или b) добавить предложения для запроса на стороне клиента или сервера для адресов, чтобы клиент получил все нужные данные.

В случае (b) вы также должны убедиться, что изменения в таблице адресов были сняты перед выполнением запросов в таблице Customer. Случай (b) прост в реализации, если есть запрос, который можно сделать для того, чтобы охватить то, какие адреса вывести.

Например, предположим, что вы создаете CRM-приложение, где клиент присваивается продавцу с помощью приложения. Затем вы присоединяетесь к клиенту и адресу и получаете только те адреса, которые принадлежат клиенту, принадлежащему зарегистрированному пользователю.