Complex Data in Mobile Services?

Question

I'm trying to learn Azure Mobile Services, and feel like I must be missing something. I've gone through the tutorials, and they all seem a little too trivial to be helpful.
I have a data model that, by traditional standards, isn't all that complicated, but seems to be for Mobile Services.  It's a reasonably straight-forward relational data model.  Whereas this is something that I would normally have designed in Entity
Framework, I'm trying to follow the "Mobile Services methodology".  I was able to create the data model in code reasonably easily, with all the classes inheriting from Microsoft.WindowsAzure.Mobile.Service.EntityData.  It seems a bit
of a step backward not to have something like the Entity Framework data model designer, but I got through it.  The database appears to get created correctly in Azure.  So far so good.
Now I want to consume the mobile service in a client.  This is where my frustration starts.  Whereas in the past there were RIA Services or a WSDL to provide the data model of the service (i.e. essentially code-gen the proxy), it appears that I
have to code everything on the client by hand again!  Is that true?!  From what I can tell, I can't even share the code between the server and the client.  Am I missing something?
Then, after I write a LOT of essentially duplicate code, I give it a try and find out that there is simply no support for navigation properties (i.e. foreign keys, etc.).  I have to code all of that myself, likely using an automapper.  Once again
I say:  am I missing something?
Please tell me there's a better way, because right now this all feels like numerous steps backward!
Thanks!
Brad.

Answer 1

You are right that there is less functionality as compared to RIA Services: this is by design. The Mobile Services tables endpoint and the client SDK are designed to be as simple as possible. This keeps your mobile client logic simple, and makes it easier
to build a cross-platform app. For instance, if you were building a native iOS and Android client, there's no way to get around the code duplication.
However, connecting to the tables endpoint is very easy using the SDK, and then you just use LINQ to run queries on your service. You can also use offline data sync to cache the data locally, and even update it while you are offline and sync changes later.
(This is another case where the simple data model is a big advantage.) Plus, there's no codegen to bloat your client app. The only thing you need to manage is the table name, but this is an API that doesn't tend to change often (usually only additions).
For a more complex example of Mobile Services, see our Field Engineer solution accelerator, which is a full-fledged app:
https://code.msdn.microsoft.com/windowsapps/Field-Engineer-501df99d
You're right that you can't share code for your model classes between client and server, other than copy and paste. :)  There's another good reason for this: the backend adds several system columns that are needed for things such as offline sync
and conflict handling. So, you have to inherit from EntityData (or IEntityData), whereas the client has no such requirement. This can actually give you a lot of flexibility. however. For instance, maybe you only want 5 database columns, and there are 20 in
your model. You can create different models on the client and backend to handle this.
We don't support foreign keys, which definitely makes things harder. Unfortunately, supporting relationships would mean the full complexity of RIA Services on all 5 of our client platforms, which just wasn't feasible.
As you noted, you can use Automapper, or, if your relationships are mostly 1-to-many, you can use database views and modify those directly. They can also be synced. If this works for your data model, it can also really simplify your client code, since you
only need very simple queries on the client. For an example of this, please see my posts in this forum thread:
https://social.msdn.microsoft.com/Forums/azure/en-US/4c056373-d5cf-4ca6-9f00-f152d2b01372/best-practice-for-syncing-related-tables-in-offline-mode?forum=azuremobile
I totally agree with you that not having support for relationships makes the developer's life much harder, particularly if the model is not a good fit with automapper. But on the other hand, you get offline data sync for free, which would otherwise be a
lot of work to implement.
In order to determine if Mobile Services is the right fit for your project, you should look at all the features in the client SDK and estimate how much work it would be to do it all yourself. If you don't need most of the features, it's possible that you
can just use Web API and all the features of Entity Framework. However, if you need things like offline data sync, login, or push notifications, the SDK can be a time saver.