For some time now Azure Mobile Services allowed developers to quickly standup a cloud based RESTful endpoint to enable cross device communication. Each instance represented an Node.js instance using ExpressJS for its routing and web configuration. This gave WAMS great power and flexibility when developing applications on the platform, all written in JavaScript. Now, Microsoft has decided to expand the offerings and permit developers to use .NET in addition to JavaScript.
Setup
.NET can only be used as a backend on new Mobile Service instances, existing instances must continue to use Node.js. When creating a new Mobile Service the backend drop down will be visible enabling selection of .NET as a backend. Notice that .NET as a backend is still very much in the preview stages, so much of how it works can (and likely will change).
Unlike with Node.js, the .NET option will require more code to be written by you in Visual Studio as opposed to the web. The entire backend is written as a Web API v2.0 application. This will entail that code must be uploaded to Azure. Currently this is done, as with Azure Websites, with a Publish file, which can be downloaded from the Dashboard.
When developing locally, the solution can be run as a normal Web API through either Kasini, IIS Express, or IIS itself. Create a separate application to access the Web API. For your convience, Microsoft provides a starter application for Windows 8, Windows Phone, and iOS under the lightening cloud icon.
Again, the essence, right now, of the .NET backend is nothing more than a Web API back end.
Controllers
If you have worked with an MVC type framework in the past you should be very familiar with Controllers as the main points of logical facilitation in an application. When you create controllers in your Mobile Service .NET application there is an important distinction to be made between the controller base type. Here is an example of a controller whose calls will talk to an actual table. This code is taken directly from the Todo starter application.
public class TodoItemController : TableController { protected override void Initialize(HttpControllerContext controllerContext) { base.Initialize(controllerContext); mytestappContext context = new mytestappContext(Services.Settings.Name.Replace('-', '_')); DomainManager = new EntityDomainManager(context, Request, Services); } }
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
This is an example of a controller which will represent at Custom API endpoint.
public class NumberController : ApiController { }
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
This distinction is very important. As with Node.js the deployment and routing of your service does get mutated as it is published.
Controlling Access
In the past, when you created an endpoint in Mobile Services, whether it was a Custom API endpoint or a Table, access to that endpoint was defined in the web interface. However, one of the first things to notice with a .NET backend is the reduced number of options available.
The reason is, with .NET as your backend, you are given much more intimate access to the underlying mechanics, at least in the current preview; this is one thing I expect to likely change moving forward. For the time being access is controlled using the RequiresAuthorization attribute and the AuthorizationLevel enum. Here is an example
[RequiresAuthorization(AuthorizationLevel.Anonymous)]
public string Get()
{
var newGuid = Guid.NewGuid().ToString();
return newGuid.Split(new[] {'-'})[0];
}
}
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
The AuthorizationLevel enum provides four levels of access:
- Anonymous
- Application
- User
- Admin
By providing these features you can restrict the allowed connection to the particular endpoint.
Connecting
In terms of opening a connection to Mobile Services from a connected device the code is no different than it was when talking to a Node.js backend, nor would I expect it to be different. Here is an example of the code for connecting to our Numbers controller.
public static MobileServiceClient MobileService = new MobileServiceClient("http://mytestapp.azure-mobile.net/", "APP KEY"); private async void AddNumbers(object sender, RoutedEventArgs e) { var result = await MobileService.InvokeApiAsync("Number", HttpMethod.Post, new Dictionary<string, string> { {"num1", Number1.Text}, {"num2", Number2.Text} }); SumOutput.Text = result.ToString(); }
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
This code would be no different if you were talking to Node.js backend. This is where that distinction between ApiController and TableController becomes important in whether you call GetTable or InvokeApiAsync passing the appropriate verb.
Forward Thoughts
So I am not covering talking to a database in this section cause I havent delved as deeply into that I would like. What it appears is that a local MDF is used locally. Now, I would assume some sort of transformation takes place when the publish occurs so that it will use SQL Azure, otherwise it would not make any sense given the size restrictions for SqlCE databases.
All of this, I can say, is backed by Code First Entity Framework, hence you will receive a custom context and fully decorated entity (TodoItem) when you download the starter project. I want to cover this and Scheduled Jobs in more detail in my next posting.
Random Blurbs and Things of this Nature 