2016-07-13 10 views
1

Я не думаю, что в SDK Azures Mobile Services SDK (в частности, в автономном режиме синхронизации) есть проверка подлинности модели/свойства коробки.Проверка на стороне клиента для мобильных услуг Azure

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

Так что материал, который мы привыкли на клиенте, с использованием чего-то вроде sqlite-net (или подобного) недоступен. Напр.

[Max(42)] 
public int Foo { get; set; } 

[Min(1)] 
public int Bar { get; set; } 

[Required] 
[MaxLength(42)] 
public string Baz { get; set; } 

// and so on 

Поэтому нам нужно сделать что-то обычай. Проверки атрибутов сами легко осуществить, что-то вроде:

[AttributeUsage (AttributeTargets.Property)] 
public class MaxAttribute : Attribute { 
    public int Value { get; private set; } 
    public MaxAttribute (int value) { 
    Value = value; 
    } 
} 

Но те рода атрибуты должны быть проверены где-то, и я не знаю, где бы хорошее место.

Есть асинхронные вызовы для операций CRUD, а также для синхронизации push и pull. Также необходимо учитывать, что произойдет после сбоев проверки модели/свойств и, по-видимому, прервать нажатие. Но это становится сложно, поскольку есть простые и пакетные перехватчики в зависимости от того, используется ли «обработчик синхронизации».

Мне никогда не приходилось писать свою собственную проверку до сих пор. Итак, для тех из вас, кто сделал что-то подобное ... где было бы хорошим местом для проверки этих атрибутов?

+0

Возможно, есть способ использовать 'System.ComponentModel.DataAnnotations', но я сомневаюсь, что это PCL, и поэтому probbaly не будет работать в мобильных приложениях Xamarin. –

+1

Если вы пишете пользовательское локальное хранилище, вы можете сделать проверку на наличие обновлений там. Выполнение проверки в обработчике синхронизации, вероятно, слишком поздно, поскольку пользователь уже внес изменения и теперь хочет их синхронизировать. Почему бы не сделать валидацию в пользовательском интерфейсе? –

ответ

1

Когда я создаю приложения Xamarin, я создаю интерфейс (скажем ITable<T>), в котором реализована реализация CRUD (т. Е. AddRecord (T item)). Тогда у меня будет конкретная реализация (например, AzureTable), которая реализует интерфейс. Это кажется ненужным накладными расходами, но я могу использовать MockTable в качестве конкретной реализации и реализовать издеваемую таблицу данных, чтобы я мог протестировать, не беспокоясь о бэкэнд.

Эта конкретная реализация - отличное место для проведения такого рода проверки. Он позволяет использовать существующий магазин SQLite, который Azure Mobile Apps распространяет и поддерживает.

В моем примере я бы сделал public class AzureTodoItemTable : ITable<TodoItem>, а затем осуществил AddRecord(TodoItem item) - проверил ограничения в этой точке.

+0

А это был ключ, который мне нужен. Так что вы говорите, что вся логика проверки должна выполняться (непосредственно в классах репозитория или в пользовательском кеше, как предложено @lindydonna) против ЛОКАЛЬНЫХ изменений в локальном магазине. НЕ до/во время синхронизации, потому что это не только слишком поздно, но теоретически вы неявно принимаете действительность данных, позволяя им проникнуть в ваш локальный кеш. –

+0

Для тех, кто читает это, я «заимствовал» некоторые валидаторы DataAnnotation и использовал их как атрибуты свойств модели. Затем были реализованы типизированные классы репозитория, такие как «ITable » или «ICustomerRepository» и т. Д., В которых есть крючки для проверки ограничений во время следующих операций: добавление, обновление и удаление (если у вас есть отношения, но это сложно). Вам нужно провести некоторое отражение, чтобы найти украшенные свойства, но это быстро и на стороне клиента, поэтому не беспокойтесь об этом. Вы можете выполнить проверку свойств только, или получить фантазию и выполнить проверку полной модели, как на сервере. –