Mobile services is a great boon for developers like myself that have mainly had contact with web or windows only applications in the loosest sense. What I’ve found myself doing is coveting parts of mobile service applications but not the whole. Whilst the authentication piece and data management are indeed incredibly useful if you’re developing a greenfield solution, in the event that you have an existing investment in an ORM such as Entity Framework or nHibernate it’s not much use.
Having authentication providers means that you can avoid implementation of something like DotNetOpenAuth in your application. The truth is however, that mobile services is what it says it’s a service for mobile developers so in effect authentication would be used directly from a mobile device as would all of the services it provides. When you have an existing application which acts as a relying party you would want to use this to
The case I’m considering though is when you have a complex application which requires reuse of an existing deployment. Well generally you could deploy the application to a cloud service and there would be a number of ways you could leverage some of the services in mobile services.
Let’s say in my application I already have a Users table in the dbo namespace. I would be able to use simple Sql statements against this to get my user information such as:
SELECT * FROM DBO.USERS
If we go back to my original post on notifications here let’s say that I wanted to create a Channels table as in the post. I could use the same database as my users table by configuring mobile services to use this table as per this image:
Mobile Scheduler
How I create the Channels table is relevant here because I want mobile services to be aware of it but all of the inserts will be occurring through my cloud service application.
Mobile Architecture
If EF I might build my DbContext in the following where the schema is the name of the mobile service. The Channels model could have a foreign key constraint which would be the UserId from the dbo.Users table and every time I created a new user I could add the Channel through EF. Doing it this way would avoid any code executing on the Insert as we wouldn’t have used mobile service’s REST API to do the insert.
Let’s assume that we have a table which captures the notifications that an Administrator wants to send to the users. The table could be called dbo.Notifications. The mobile services application, like the dbo.Users table would not be aware of this.
So we could create a new Scheduled job and pickup the notifications every few minutes, send to all of the ChannelUri’s in the Channels table and then delete the rows from the Notifications table.
In order to select this using and kicked off by a scheduled job (you can read about scheduled jobs here) we could write a node function set like so:
I wanted to present a very simple reuse pattern here which leverages a key service provided by mobile services which can fit into your existing application. Microsoft has provided alternatives to this with a new notification hub using the Service Bus but the pattern described here is a viable low cost alternative. It’s important to note that the Channels table does not need to be in the mobile services schema in this example – the benefit of doing so however is that you can make a request of some kind – an update or delete of the channel, for example and send a message to the user’s device using a script.
Yes.Very good article.