Azure Mobile Service - Primeiros passos com backend .NET WebAPI

Cloud Computing & Microsoft Azure & Mobile

O Microsoft Azure Mobile Service (MAMS) é um serviço que oferece backend escalável, seguro e multiplataforma, e teve como origem o NodeJS para backend server-side. Um dos pontos mais interessantes do MAMS é a capacidade de dar ao programador o poder de customizar e adicionar lógica ao backend.

A ideia neste post é trazer uma primeira visão sobre o Microsoft Azure Mobile Service com backend .NET.

FIG015

Assim que a Microsoft anunciou o backend .NET para o MAMS, ouve uma  grande aceitação da comunidade, principalmente dos desenvolvedores .NET.

Minha primeira impressão em relação ao backend .NET era que isso se dava apenas pela falta de familiaridade dos desenvolvedores .NET com o código JavaScript server-side, e tiro isso por mim, porém isto não é de todo verdade

O novo backend .NET te traz mais poder de customização em relação ao NodeJS, porém como diria o tio Ben Parker, grandes poderes trazem grandes responsabilidades. Sendo assim o poder de customização também traz consigo a necessidade de um arcabouço de conhecimentos  que muitas vezes não fazem parte de quem está trabalhando com APPs: WebAPI, Self Hosting, Injeção de Dependência, Entity Framework etc...

 

Principais Diferenças entre o backend .NET e o backend JavaScript

  • Você precisa definir suas tabelas e data-model usando Code First
  • O backend .NET usa Web API 2. Actions e Controller Methods
  • Você tem que definir as permissões de acesso para os métodos
  • Alterações no modelo de dados devem ser propagadas usando Entity Framework Code First Migrations
  • A forma padrão para enviar notificações push é utiliznado o Notification hub

 

Diferenças no portal de gestão do Microsoft Azure Mobile Service

O primeiro passo é acessar o poral de gestão do Microsoft Azure. No exemplo abaixo estou acessando a área de Mobile Service e exibindo os menus de dois serviços diferentes.  O primeiro com backend .NET chamado meriatwebapi e o segundo com o backend NodeJS chamado meriatnodejs.

FIG01

Apenas de olhar já conseguimos ver algumas mudanças: As opções DATA e API não estão disponíveis para o backend .NET. Existem ainda algumas diferenças internas que podemos ver acessando os itens específicos do menu. São eles:

PUSH

Agora por padrão é criado um Notification Hub para o backend .NET.

FIG02

Já para o ambiente JavaScript precisamos habilitar o "Enhanced Push" para o mesmo cenário. Lembrando que isso vale para os serviços já criados.

FIG03

 

CONFIGURE

Note que na sessão Source Control não temos as seguinte opções em .NET

  • Dynamic Schema
  • Cross-Origin Resource Sharing (CORS)

Em NodeJS é uma boa prática utilizar o GIT para gerenciar os scripts, o que é desnecessário no caso do backend .NET onde o serviço é compilado. A vantagem do NodeJS é que por ser interpretado podemos ter as alteração publicadas de maneira mais simples.

FIG05

Também não temos a opção de dynamic schema, que por sinal é algo muito bom no NodeJS, onde é possível forçar que o esquema do Banco de Dados se ajuste utilizando como modelo o JSON do request para operações de inserçao ou alteração. Em .NET trabalhamos com WebAPI e controllers fortemente tipados.

No backend .NET o controle de CORS é feito programaticamente seguindo o modelo do WebAPI, logo também tornou-se desnecessária.

 

Criando um serviço com backend .NET

Vamos dar uma olhada na estrutura do projeto padrão. Para isso acesse o portal do Microsoft Azure e crie seu mobile service com backend .NET. É muito simples, basta clicar na opção + NEW, selecionar COMPUTE, MOBILE SERVICE e clique em CREATE.

FIG06

Na tela que se segue informe o Nome/URL do serviço, o Database que pode ser um existente, uma nova instância de SQL ou uma opção FREE e compartilhada de 20MB. Selecione também a Região/Datacenter e é claro, como BACKEND a opção .NET e vá para o próximo passo.

FIG07

No próximo passo é a área de Database Settings, onde você vai fornercer as configurações para o novo banco ou apenas informar a senha de um banco já existente. Para mais informações sobre a criação de Serviços no Azure Mobile Services vide referências.

 

Estrutura do projeto

Existem dois caminhos para analisarmos a estrutura de um projeto Windows Azure Mobile Service: Baixando a aplicação atravéz do portal ou criando via Visual Studio.

Para baixar um exemplo do projeto funcional via portal Azure é só acessar o seu projeto MOBILE SERVICE e  clicar na NUVENZINHA, expandir a opção CREATE A NEW WINDOWS STORE APP (pode ser qualquer cliente mas neste exemplo estou utilizando esta opção), e selecionar a linguagem da aplicação. Isso não afeta o serviço que é WEB API.

FIG08

Para criar um novo projeto via Visual Studio, é só acessar o VS2013 Update 2, selecionar a linguagem, menu Cloud, selecionar o .NET Framework 4.5.1 e o template Windows Azure Mobile Service como na imagem abaixo:

FIG09

A próxima tela é apenas de aceite…  até o presente momento as outras opções são apenas de leitura.

FIG010

A estrutura final do projeto será como se segue na abaixo:

FIG011

Note que eu estou apontando as pastas que foram criadas por padrão no template. Vou estar abordando resumidamente cada uma, bem como sua ligação com o modelo NodeJS.

 

DataObjects

Aqui temos uma classe de exemplo "TodoItem.cs" com apenas duas propriedades:

COD01

Você vai notar no entanto, que não é apenas um POCO, ele realmente tem uma classe base "EntityData", que é uma implementação abstrata de “Tables.ITableData". Este cara é responsável pela representação do modelo base:

COD02

 

Models

Por padrão nosso "serviçoContext.cs" (no meu caso meriatwebapiContext) é criado com um Entity Framework DbContext padrão.

COD03

 

Controllers

O controlador implementa a classe base “TableController<T>” que se derivada de TableController e ApiController. O EntityDomainManager é responsável por gerenciar o acesso ao contexto de banco de dados do EF.

COD04

 

App_Start

O “WebApiConfig” contém o código para iniciar o serviço Web API e Entity Framework. Aqui temos uma classe seuserviçoInitialiser criada por padrão apontando para o contexto original e que herda de DropCreateDatabaseIfModelChanges<T>.

COD05

 

Scheduled Jobs

A classe 'SampleJob' traz um exemplo de como criar JOBs para serem executados sob demanda ou agendados. É importante citar que esta classe não é um componente do WebAPI porém deriva de um controller.

COD06

Aqui temos nosso esqueleto do ScheduleJob, que deriva de um JobsController e não de uma ApiController padrão. Mesmo assim ele é chamado através de uma solicitação POST:

COD07

 

Rodando localmente

Um dos benefícios do backend .NET é a capacidade de rodar e testar seu serviço e o armazenamento localmente, só dependendo do deploy da aplicação.

Vamos utilizar o projeto que criamos acima para testar nosso serviço modelo criado por padrão no template da aplicação,  simplesmente apertando o famoso F5. Abaixo segue o exemplo do serviço rodando localmente:

FIG012

Note que na tela inicial temos um help. É só acessar o link try it out. A tela abaixo mostra o exemplo do help que traz uma mini-documentação de como utilizar o serviço:

FIG013

Como vimos no acima, podemos utilizar o GET para obter o retorno JSON do nosso serviço.

FIG014

 

E a IDE?

Do lado do Visual Studio temos muito mais do que apenas diferinciar os serviços pelos ícones.

code23

Temos duas opções ótimas e simples de utilizar: Attach Debugger e View Logs. Vou abordar com mais detalhes sobre estes itens nos próximos posts.

code21

code22

 

Referências:

http://azure.microsoft.com/blog/2014/07/28/azure-mobile-services-net-updates/

http://msdn.microsoft.com/en-us/library/windows/apps/xaml/dn629482.aspx

Bons estudos e até a próxima pessoal  ;)


Author's profile picture

Vitor is a computer scientist who is passionate about creating software that will positively change the world we live in.

MVP Azure - Cloud Architect - Data science enthusiast


8 minutes to read