Utilizando DocumentDB Provider com Identity 2.1

No dia 8 de Abril de 2015 foi definitivamente lançado para o mercado um novo mecanismo conceito de armazenamento de dados que a Microsoft libero como mais um novo recurso no Windows Azure: DocumentDB.

Por muito tempo, esse mecanismo de armazenamento de dados foi utilizado por projetos internos dentro da Microsoft (acredito eu como uma PoC – Proof of Concept/Prova de Conceito) e que só agora eles decidiram lançar este novo produto como serviço na nuvem, passando a integrar o DBaaS (Database as a Service/DB como Serviço). O DocumentDB vem para brigar forte com os grandes players desse mercado de Document Database, como: RavenDB, MongoDB, por exemplo. Antes, vou apresentar uma breve história e descrição sobre algumas características e comportamentos do DocumentDB, e em seguida mostrarei como podemos criar um novo Provider e integra-lo com uma base de dados NoSQL.

O DocumentDB nasceu para ser uma base de dados de Documentos que trabalha 100% em formato JSON e RESTful (com isso suas consultas independem do schema JSON) e seu serviço encontra-se disponível apenas no novo portal do Windows Azure – para que ainda não habilitou o novo portal do azure e quer utilizar o serviço do DocumentDB, será necessário habilitar no seguinte endereço: https://portal.azure.com ou mesmo dentro do portal antigo quando for exibida uma popup para ativar o novo portal. Como o serviço é 100% com base no portal do Windows Azure, você não precisa montar nenhuma infraestrutura ou criar nenhuma VM dentro do Azure para trabalhar com esse recurso. Toda a intervenção que seja necessário realizar em uma base de dados, pode ser realizada ou por meio do portal Azure ou via serviço REST.

Com essa versão atual, as opções de utilização são amplas (mas nada se compara ainda ao MongoDB, por exemplo), podendo serutilizado com conectores: .NET, Node.js, Javascript e Python.

Consultas

Todas as consultas realizadas, por meio da API do DocumentDB são baseadas em um formato SQL, o que eles chamam de *SQL-Like *e, além disso, como todo o serviço é baseado em JSON, você pode utilizar funções Javascript dentro das suas consultas SQL, o que faz suas consultas aos dados serem mais flexíveis, e onde eu posso ir? O céu é o limite :D.

SELECT * FROM Usuarios U WHERE U.Nome = 'José Araujo'

para maiores de detalhes sobre como utilizar os recursos de consulta segue o link da página oficial: DocumentDB Doc.

Transação

Todos os comandos que são executadosno DocumentDB são realizados por meio de transações, garantindo que a informação tenha sua consistência garantida, utilizando-se do conceito ACID. Onde qualquer problema em persistir os dados no banco, será enviado uma informação para a aplicação.

Performance

O DocumentDB possui 3 níveis de cenários de performance: S1, S2, S3. Quando você criar o seu primeiro Data Store dentro do Azure, a máquina alocada será uma máquina para um cenário S1, mas não precisa criar maiores preocupações em termos de alocação dinâmica, porque a qualquer momento, dependendo da sua demanda, a alocação entre as máquinas S1, S2 e S3 é completamente transparente para a aplicação que estiver consumindo o serviço DBaaS. Cada máquina possui suas próprias garantias de performance, níveis de taxa de transferência reservada e toda requisição é processada com base em HDs do tipo SSD para garantir uma alta performance de escrita e leitura dos dados.

A indexação é um mecanismo que chama-mos de: Builtin, ou seja, o DocumentDB já nasceu com seu recurso de indexação automatizado, o que garantirá uma melhor armazenagem dos dados e uma leitura ainda mais performática.

Você precisa realizar algum processo de Tunning? Não criemos pânico :D, a infraestrutura do DocumentDB fornece recursos para criação de Políticas de índices e níveis de consistência, fornecendo um serviço de base de dados na nuvem de alta performance, poderoso e bastante flexível.

Como migrar os dados para o DocumentDB ?

Não precisam ficar desesperados :). A Microsoft lançou junto com a liberação do DocumentDB uma ferramenta de migração dos dados que dá suporte a vários formatos, tais como: CSV, JSON, SQL Server, MongoDB e até mesmo base de dados antigas do próprio DocumentDB.

Mãos obra

Esse artigo não tem o objetivo de explicar em detalhes todos os processos necessários para criar um novo provider para o Identity 2.1,mas sim mostrar como podemos utilizar um provider disponível pela própria Microsoft e podermos ter outra opção de armazenamento dos nossos usuários em uma estrutura NoSQL :).

Para iniciarmos, crie um novo projeto ASP.NET MVC e deixei selecionada a opção: Individual User Accounts, como mostra marcado em vermelho na imagem abaixo:

Criar novo projeto aspnet mvc

Agora com seu projeto MVC criado, você já tem toda a infraestrutura criada para trabalhar com o Identity, só que vinculado ao Entityframework, o que não é o caso do nosso artigo. Agora eu preciso mudar toda a infraestrutura já criada do meu projeto? Não. Não será necessário mudar muito o seu projeto. Como primeira mudança, será necessário instalar o conector do DocumentDB disponível no site do Nuget, como mostra o comando abaixo:

Install-Package DocumentDB.AspNet.Identity -Pre

Após a instalação do conector do DocumentDB, seu projeto MVC estáconfigurado para começar algumas pequenas alterações.

O primeiro arquivo que soferá mudanças é o IdentityConfig.cs. Nesse arquivo você precisa substituir o código abaixo:

using Microsoft.AspNet.Identity.EntityFramework;  

por uma nova referência:

using DocumentDB.AspNet.Identity;  

Isso vai fazer com que a a referência a classe UserStore seja a que encontra-se no assembly DocumetDB.AspNet.Identity e não mais a do Entityframework. Uma outra pequena alteração será realizada no trecho de código onde é instanciada a classe ApplicationUserManager, a mudança segue no código abaixo:

var urlEndpoint = ConfigurationManager.AppSettings["urlEndpoint"]; var authKey = ConfigurationManager.AppSettings["authKey"]; var authDb = ConfigurationManager.AppSettings["authDb"]; var manager = new ApplicationUserManager(new UserStore<ApplicationUser>(new Uri(urlEndpoint), authKey, authDb));  

O trecho de código acima, apresenta 3 variáveis que recuperam as seguintes informações do web.config: URL de acesso ao serviço DocumentDB, chave de autentivação e nome da base de dados, para realizar a conexão com a sua infraestrutura do DocumentDB dentro da sua conta no WindowsAzure (o artigo não cobre uma configuração de todo o ambiente no azure para o DocumentDB).

Feita a substituição no seu projeto, utilizando o trecho de código acima, o outro ponto de alteração será no arquivo Startup.cs removendo a linha que faz o registro do contexto do Entityframework, conforme trecho de código abaixo:

app.CreatePerOwinContext(ApplicationDbContext.Create);  

O último ponto de alteração será no arquivo IdentityModels.cs, onde será necessário remover o trecho de código:

using Microsoft.AspNet.Identity.EntityFramework;  

E adicionar o trecho de código:

using DocumentDB.AspNet.Identity;  

agora comente/remova o trecho de código abaixo:

public class ApplicationDbContext : IdentityDbContext<ApplicationUser> { public ApplicationDbContext() : base("DefaultConnection", throwIfV1Schema: false) { } public static ApplicationDbContext Create() { return new ApplicationDbContext(); } }  

Pronto, agora você pode executar sua aplicação.

Espero que tenham gostado. E até a próxima 🙂

O código fonte do exemplo você pode encontrar no meu Github

Referências

Comments