Entrar Ainda não tem acesso?
3
respostas

.Net Core - Arquitetura de projeto com aplicações MVC e Mobile

Referente ao curso ASP.NET Identity parte 1: Gerencie contas de usuários

por Jose Wallace Ribeiro de Macedo Junior
| 123.7k xp | 3 posts

Pessoal, Tenho um projeto que será composto de uma app WEB MVC e app mobile com Xamarim. Tenho dúvidas em relação à arquitetura da aplicação. Pensei em duas abordagens:

1) Criar três projetos: um WebMVC, Xamarim e um para a API. Tanto app mobile quanto à MVC chamariam a API, onde ficaria concentrada toda a regra de negócio;

2) Criar quatro projetos: um WebMVC, Xamarim, um para a API e um para Regra de Negócio. Nessa abordagem, a API (usada pela app mobile) e a MVC usuariam esse projeto com as regras de negócio centralizadas.

Gostaria de uma ajuda sobre qual seria a melhor opção.

3 respostas
por Marcelo Oliveira
| 977.3k xp | 1845 posts
Alura Scuba Team

Oi José, tudo bem?

Eu recomendaria você ter um projeto à parte com ASP.NET Identity, para gerenciar o login, autenticação e os tokens. Assim, esse projeto seria usado para login dos usuários tanto no ASP.NET Core MVC quanto no Xamarin.

Quanto às opções 1) e 2) acima, acho bom ter um projeto para regras de negócio, que pode ser escrito como um projeto do tipo .NET Standard, pois assim ele pode ser usado na solução web como também na Xamarin.

por Jose Wallace Ribeiro de Macedo Junior
| 123.7k xp | 3 posts

Obrigado, Marcelo. Tenho mais uma dúvida em relação à autenticação e autorização. Vou precisar ter diversos perfis de acesso, sendo que cada vai ter acesso a determinadas funcionalidades da aplicação. Esse cadastro de perfis/funcionalidades ficaria na aplicação MVC ou no Identity Server? Se for no IDS, eu colocaria todas as informações de acesso no token?

por Marcelo Oliveira
| 977.3k xp | 1845 posts
Alura Scuba Team

Ficaria no serviço do ASP.NET Identity. Assim, a aplicação MVC se torna cliente dela, verificando, por exemplo, se os "papéis" ou "funções" (roles) do usuário podem dar a ele o acesso a um recurso protegido (como um controller ou uma action). Por exemplo:

[Authorize(Roles = "Financeiro,RH")]
public class SalarioController : Controller
{
}

ou:

[Authorize(Roles = "Administrator")]
public class AdministrationController : Controller
{
}

Note que esses "roles" de Administrador, RH e Financeiro de cada usuário seriam definidos no seu serviço de Identity, não no MVC. Isso porque sua arquitetura já está prevendo essa separação (Mas nada impede de você criar um projeto só e colocar tudo dentro dele - tanto a parte do MVC quanto Identity).

Você pode pegar mais informações neste documento da Microsoft:

https://docs.microsoft.com/pt-br/aspnet/core/security/authorization/roles?view=aspnetcore-2.2