Client-side model validation for Azure mobile services

Question

I don't think there's out-of-the-box model/property validation in the Azure's Mobile Services SDK (specifically the offline sync stuff).

One can perform validation on the server, but we'd like to perform validation and cleaning on the client as well, as is done for web apps.

So stuff we're used to on the client, using something like sqlite-net (or similar) isn't available. For e.g.

[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

So we need to do something custom. The validation attributes themselves are easy to implement, something like:

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

But those sort of attributes need to be checked somewhere, and I'm not sure where would be a good place.

There are async calls for CRUD operations, and for push and pull syncing. One also needs to take into account what would happen after model/property validation failures, and presumably abort the push. But it gets tricky as there are simple and batch push interceptors depending on whether one uses a "sync handler".

I've never needed to write my own validation till now. So for those of you who've done something similar... where would be a good place to perform the checking of these attributes?

Maybe there's a way to use System.ComponentModel.DataAnnotations, but I doubt that is a PCL and so probbaly won't work in Xamarin mobile apps. — h bob
If you write a custom local store, you can do validation on updates there. Doing validation in the sync handler is probably too late, since the user has already made changes and now wants to sync them. Why not do validation in the UI itself? — lindydonna

Adrian Hall Adrian Hall · Accepted Answer · 2016-07-14T00:42:50

When I produce Xamarin apps, I create an interface (say ITable<T>) that has the CRUD implementation in it (i.e. AddRecord(T item)). Then I'll have a concrete implementation (e.g. AzureTable) that implements the interface. This seems like un-necessary overhead, but I can use MockTable as a concrete implementation and implement a mocked data table so I can test without worrying about a backend.

This concrete implementation is a great place to do this sort of checking. It enables you to use the existing SQLite store that Azure Mobile Apps distributes and supports.

In my example, I'd do public class AzureTodoItemTable : ITable<TodoItem> and then implement AddRecord(TodoItem item) - checking the constraints at that point.

Client-side model validation for Azure mobile services

1 Answers