Olá pessoal, tudo bem? Venho percebendo há algum tempo, nas comunidades que frequento, uma necessidade grande de aplicar vários conceitos de arquitetura de software dentro de um projeto web como: DDD, TDD, BDD, ATDD, SOLID, CrossCutting e por ai vai. Mas como criar uma boa arquitetura? Algumas pessoas muitas vezes, seguem a onda das sopas de letrinhas e idéias que nós da comunidade divulgamos, abordamos e constatemente estamos falando e com isso tentam implementar esses conceitos dentro de seus projetos, em alguns casos sem ao menos procurar saber o porque, o pra que e ler um pouco sobre o assunto. O que acontece com isso? Dúvidas, MUITAS dúvidas.

Mas e qual será a melhor forma de construirmos um projeto de software seguindo um Guide Line de arquitetura? Bom, para isso eu não gostaria de decepcionar você, mas NÃO existe um GUIA para criar uma arquitetura de software. O que podemos apresentar é um caminho, uma linha de pensamento e seguir boas práticas em basadas em conceitos bem difundidos e fundamentados.

Nas minhas caminhadas por ai, vi bastante gente falando sobre AspNet Identity, indicando que era melhor isso ou aquilo outro. Era melhor trabalhar com um projeto de CrossCutting, pera melhor criar um projeto separado para isso, buscando isolar o AspNet Identity do Front-End e assim termos uma transversalidade no acesso ao mecanismo de autenticação, autorização e controle de usuários do Identity. Mas ai é que entram as dúvidas de algumas pessoas na cominidade AspNet.

Devido as várias dúvidas que venho percebendo na comunidade, escrevi uma aplicação Demo mostrando como você pode criar uma aplicação AspNet MVC utilizando um projeto separado da sua camada de Front-End, onde toda a responsabilidade de Autenticação, Autorização e controle do usuário de sua aplicação está dentro de um projeto de CrossCutting. Mas pera ai! Tanto se fala nesse termo, mas o que esse termo significa?

Cross-Cutting

O conceito de crosscutting é perceptível quando você está aplicando Aspect Oriented Programming (AOP), onde um metadado é usado pode ser inserido, em tempo de compilação, ao código que será gerado na aplicação ou durante o tempo de execução da aplicação. Com isso, temos um código ou parte dele (metadado) que será transversalmente utilizado pela aplicação.

Esse conceito de crosscutting é que nos leva a criar um projeto separado para tratar de algumas funcionalidades dentro de um projeto, as quais serão utilizadas transversalmente dentro do projeto. Tais funcionalidades estão listadas abaixo:

  • Authentication
  • Authorization
  • Caching
  • Communication
  • Configuration management
  • Exception (Error Handling)
  • Loggin
  • Validation

O que existe em comum em cada uma dessas funcionalidades? Elas são utilizadas, na maioria das vezes em seu projeto, por várias camadas e/ou níveis de sua aplicação? Ok, mas qual o ganho que eu tenho colocando isso num projeto usando um nome diferente? O nome do projeto, não importa muito, mas sim o conceito precisa ser compreendido. A utilização dessas funcionalidades em um projeto separado (crosscutting), possibilida:

  • Unicidade de implementação
  • Reutilização do código
  • Escalabilidade
  • Flexibilidade

Se você perceber, eu fiz questão de sinalizar em negrito as duas primeiras funcionalidades: Authentication e Authorization. Essas são funcionalidades que estão intrissicamente ligadas e implementadas dentro da Engine do AspNet Identity, que sofreu ao longo de suas implementações até a versão 2.2. Antes de mostrar o que esse artigo se propõe a apresentar. Abaixo segue uma imagem apresentando como está as camadas de acesso do AspNet Identity:

Camadas do AspNet Identity
AspNet-Identity-Layers

 

 

 

 

 

 

 

 

 

Herança e Implementação da classe Role AspNet Identity
AspNet-Identity-Customization

 

 

 

 

 

 

 

 

 

 

 

 

Como você mesmo pode observar existem diferente camadas, cada uma com suas respectivas responsabilidades e possibilidades de customização. O que para nós DEVS 😀 é excelente, pois com essa flexibilidade não precisamos ser obrigados a utilizar o mecanimos de autenticação/autorização dentro de nossa camada de Front-End (UI).

Para isso demonstrar como podemos trabalhar com o conceito de crosscutting e separar as responsabildiades dos projetos, funcionalidades e utilizar um pouco de IoC, criei uma demo onde contendo apenas 2 projetos:

  • Infrastructure
    • Projeto que aplica o conceito de crosscutting, contendo:
      • AspNet Identity
      • IoC utilizando Microsoft Unit
    • WebAppIdentityDemo
      • Projeto web que consome as funcionalidades do projeto Jra.Infrastructure

O que foi feito nesse demo foi criar um projeto AspNet MVC sem nenhum tipo de autenticação e um outro projeto do tipo Class Library vazio (Jra.Infrastructure), onde lá instalei e configurei alguns pacotes através do nuget, utilizando os comandos abaixo:

  • Install-Package Entityframework
  • Install-Package Microsoft.AspNet.Identity.Entityframework
  • Install-Package Microsoft.AspNet.Identity.Owin
  • Install-Package Unity.Mvc

Além desses pacotes que precisam ser instalados no projeto de infraestrutura, será necessário que você referencie os assemblies:

  • Web.Http
  • Web.Mvc

Tanto os pacotes instalados e os assemblies referenciados, são necessários para que toda a estrutra do AspNet Identity possa ser configurado corretamente, dentro desse exemplo que fiz. Lembro que, esse exemplo não é um MODELO de arquitetura nem muito menos uma maneira CORRETA de implementar a separação do Identity, mas sim um caminho e uma forma simples de como você pode separar as responsabilidades em projetos distintos.

Abaixo segue a imagem da solução com os projetos separados:

WebAppIdentityDemo-Solution

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
Bom pessoal, como falei anteriormente esse artigo não tem a intenção de ser nem de perto um Guide Line de como implementar um modelo de arquitetura de software, mas o objetivo aqui foi de mostrar um pouco sobre o conceito de Crosscutting e demonstrar através de um projeto simples, como podemos separar o AspNet Identity em um projeto a parte e não colocarmos todas as dependências dentro do projeto de Front-End. Com isso ganhamos em: Reuso, Escalabilidade, Flexibilidade e Transversalidade do uso comum dessas funcionalidades em nosso projeto.

Baixem a aplicação, estudem a estrutura, estudem como o AspNet Identity se comporta, no site oficial do Identity tem bastante conteúdo e muitos exemplos. Espero que gostem do exemplo.

Aqui o link do meu Github para baixar o código da aplicação. Até a próxima !!!

Referências

jroberto.araujo

Comentários

comentarios